From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fg3ra-0004Ya-BQ for garchives@archives.gentoo.org; Tue, 16 May 2006 18:01:42 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4GHu950031920; Tue, 16 May 2006 17:56:09 GMT Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4GHdPcq029325 for ; Tue, 16 May 2006 17:39:25 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc13) with SMTP id <20060516173924m1300fc7kre>; Tue, 16 May 2006 17:39:24 +0000 Date: Tue, 16 May 2006 10:39:14 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060516173913.GD28745@nightcrawler> References: <20060516161549.442b4d8a@localhost> <20060516161618.GB28745@nightcrawler> <448EF5C9.6040900@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline In-Reply-To: <448EF5C9.6040900@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: 73a923b4-047d-46c8-913b-ffd6e2ad70e3 X-Archives-Hash: 64b096f71f989edbcef6335c43a87496 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2006 at 06:28:41PM +0100, Stephen Bennett wrote: > Brian Harring wrote: > >The gain of the profile is that you can do a few new tricks for folks=20 > >doing boostrapping experiments- why not just introduce an ebuild that=20 > >sets up the new profile in a temp overlay? >=20 > No, the gain is that one could sanely run a Paludis-based system without= =20 > needing an external overlay, and without having to update said overlay=20 > whenever the base profiles in the tree change. Bluntly, why should the tree be modified for a minority? Being=20 generous, lets pretend y'all have 300 users- why should incompatible=20 changes be added to the tree (say 300k users) that can bite 299,700=20 users in the ass for the benefit of 300 users? N parent inherited=20 profiles *is* a change that can bite users in the ass, and it's not an=20 obvious incompatibility unless you know it exists. Ebuild level incompatibility is there also, and the only way that's=20 going to be resolved is by inspection of each ebuild. Note I said inspection- just the same as loosing the USE flag state=20 for when re-executing the env for an unmerge, loosing local non=20 exported vars has the same potential for change. Not opposed to y'all ironing it out in an overlay and proposing the=20 switch (with a sane transition plan)- am opposed to the "lets just do=20 it and ignore the consequences to the userbase" mentality that such=20 requests imply. ~harring --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEag5BvdBxRoA3VU0RAiabAJ0d5mJ//Ycd5ZiJb45UwqlcPSucrACg7t2y SeweQkvyHPhnp2aqH8YH9ds= =aO0Y -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- -- gentoo-dev@gentoo.org mailing list