From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-66212-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DE4CE13877A for <garchives@archives.gentoo.org>; Sat, 14 Jun 2014 16:37:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27CF9E0B1C; Sat, 14 Jun 2014 16:37:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1DD83E0AEB for <gentoo-dev@lists.gentoo.org>; Sat, 14 Jun 2014 16:37:08 +0000 (UTC) Received: from rook (unknown [96.241.16.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id 2624533FD4F for <gentoo-dev@lists.gentoo.org>; Sat, 14 Jun 2014 16:37:07 +0000 (UTC) Message-ID: <1402763759.16949.6.camel@rook> Subject: Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes? From: Alexandre Rostovtsev <tetromino@gentoo.org> To: gentoo-dev@lists.gentoo.org Date: Sat, 14 Jun 2014 12:35:59 -0400 In-Reply-To: <20140614173147.277d6974@googlemail.com> References: <20140614164151.45afb5ca@pomiot.lan> <20140614161341.6cc4c2fa@googlemail.com> <1402761029.16949.1.camel@rook> <20140614165652.046552aa@googlemail.com> <1402762672.16949.3.camel@rook> <20140614173147.277d6974@googlemail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8UgOzckll376SHggM7GU" X-Mailer: Evolution 3.12.3 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 6da6b6f4-7b03-4e67-acd1-360a08e16e00 X-Archives-Hash: 9686a9f0319b7ca2ae3acf92f2ce8d7b --=-8UgOzckll376SHggM7GU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2014-06-14 at 17:31 +0100, Ciaran McCreesh wrote: > On Sat, 14 Jun 2014 12:17:52 -0400 > Alexandre Rostovtsev <tetromino@gentoo.org> wrote: > > On Sat, 2014-06-14 at 16:56 +0100, Ciaran McCreesh wrote: > > > On Sat, 14 Jun 2014 11:50:29 -0400 > > > Alexandre Rostovtsev <tetromino@gentoo.org> wrote: > > > > On Sat, 2014-06-14 at 16:13 +0100, Ciaran McCreesh wrote: > > > > > On Sat, 14 Jun 2014 16:41:51 +0200 > > > > > Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote: > > > > > > However, this means that we force much more rebuilds than > > > > > > necessary. > > > > >=20 > > > > > This shouldn't be considered to be a problem. > > > >=20 > > > > This would be suicide for Gentoo as a distro. Organizations that > > > > have a dedicated build server and a standardized /etc/portage > > > > config tree pushed to all user machines could rebuild half of > > > > @world once a week. Individual users running Gentoo on a single > > > > workstation or server can't and won't. > > >=20 > > > Then either Gentoo should ship binary packages, or the user should > > > find another distribution. > > >=20 > > > Gentoo *already* does a full rebuild for packages whose bumps or > > > revbumps just result in one text file changing. So long as there > > > isn't a mechanism and full ebuild support in place to prevent this, > > > it's a silly argument. > >=20 > > You don't see the difference between unnecessarily rebuilding one > > package (because a text file changed) and unnecessarily rebuilding a > > hundred packages (because libfoo added a new function)? Especially > > since maintainers of packages with long compile times understandably > > tend to be a bit conservative with their revision bumps, but have no > > control over when their package's dependencies get subslotbumped. >=20 > So why isn't there a call for a feature to make ebuilds not recompile > the nine out of ten libraries and binaries that they provide that > haven't changed on a bump? I cannot speak for others, but I haven't called for such a feature because it seems to be impossible to implement. If you have an idea for how this can be done, I for one would love to hear. --=-8UgOzckll376SHggM7GU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJTnHnvAAoJEKRDAQ9PHUhguRgP/3sRq33YFffHM0qYCplN6bpI xszyNkFsMbTsGrHdixdLAuBy+dkVQFN6wIrZkEFnd3v+SRY8o5yEaO+kf50l3VSJ YQYQjw9xcL+Ya5uc+dTDHV3yZy/PLrOlJ3kolurX0lwGWYTaXotmP1PylsO+CmH3 4apIQ+dowPPEkMe/qp524Juj59z3237XwBEbogBK2UmCLHtIY94Q4D3Hph2rJStu ZmueHARw3USy95qcUSRQw1ETnD6dZ315JhwxE/L9/Uotswn405C2NnX+ZzgNMWHw fbnHGHifF/16eaxJFu22B/OX3qVhftzh2ofUUpuCgQLB3V98/RfxWV2APd/sLz6v esdhZJUdGIyPJGB75idZOGgTTEQevtAprS1ZP4kp3Fvj7w4DJjdQK6adDR+NvXyH jykLmmkGLHNwy/wbe0WAjsOpP6LQmXItxqHWsOpKb6f2YjsJfzaRDjMeZE+ytLmg ckPTjXrWGYV8DJhf+98dA9fC8X2P/8RpbPnCLN8Gmq08EV9kpxngXFWti66HkuHk 22Q40XJyA+ef+OSL+mOrNIXB/PVD6WuCaQca/qPl1glGxwtfv02gfbxocwwABrSI 8VqLaINfQV/Rq6gjbIlYHW0iLkSZSI8dVecyoppEOcvIv57+wWNaacGM9T1oOolI 5jWSg2ksU++G3FtCqWCz =Ii8g -----END PGP SIGNATURE----- --=-8UgOzckll376SHggM7GU--