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 1Fg2O6-0005rD-67 for garchives@archives.gentoo.org; Tue, 16 May 2006 16:27:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4GGMZYv018897; Tue, 16 May 2006 16:22:35 GMT Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4GGGTff001970 for ; Tue, 16 May 2006 16:16:29 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc11) with SMTP id <20060516161628m11009h873e>; Tue, 16 May 2006 16:16:28 +0000 Date: Tue, 16 May 2006 09:16:18 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060516161618.GB28745@nightcrawler> References: <20060516161549.442b4d8a@localhost> 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="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20060516161549.442b4d8a@localhost> User-Agent: Mutt/1.5.11 X-Archives-Salt: f4d9e94d-8461-4395-959a-b18739a693b9 X-Archives-Hash: 5d1df987d6ca0df6ba4c1a79071328c4 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote: > If noone has any strong reasonable objections, I'd like to add a > Paludis profile to the tree. This would use Paludis as the default > provider for virtual/portage (which is a less than ideal name, but that > is another discussion entirely), and provide ebuild devs with a place > where they can try out some of our profile enhancements should they > want to. It is worth noting on the last point that most of these are > Comments? Maybe I'm daft, but why does this need to be demoed in the live tree? =20 Use an overlay (y'all have one already anyways). Reasons why this is=20 a bit daft- 1) changes to the eapi=3D0 ebuild standard; renaming of vars=20 (PORTAGE_* -> PALUDIS_* namely), dropping of all local vars during=20 phase changes (since y'all lack ebuild, it'll rear it's head mainly=20 during unmerge), effective dropping of config phase (another place=20 it would rear it's head)... Mind you that's from a quick read through=20 of your ebuild env reimplementation, stated the issues already and=20 they still remain- incomplete support for the standard is one thing,=20 changing it is another (y'all are doing the latter). 2) N profile inheritance- the parents change (N entries instead of=20 one) needs to be protected so that specific profile is only usable by=20 a package manager (whether portage, pkgcore or paludis) that actually=20 does N parent inheritance. This is why N profile inheritance has=20 never been added to portage (it's honestly a one line change in=20 portage)- the change must not be introduced without protection,=20 else the user's system set can become drastically reduced. It's not=20 an easily addressable problem (all solutions sans a new profile=20 directory leave open the potential for users to get bit), ignoring it=20 is a no go. Yes, you're after demoing capabilities- problem is that=20 it's exposing potential horkage in a production tree, wrong place to=20 be demoing. 3) vdb CONTENTS change of dev/fif to misc. It's dumb, but that change=20 renders vdb entries incompatible- iow, proper usage/conversion to=20 paludis requires a new installation (or translation script, both=20 to/from portage). So... short version, introduction of the profile allows for curious=20 users to get bit in the ass by intentional dropping of compatibility=20 (profile level changes are one thing, changing the ebuild standard is=20 another). In light of that, why should it be demoed in the tree where=20 the only use of it is to bootstrap a new installation? Just overlay=20 it, y'all should be maintaining an overlay fixing ebuild incompatibilities= =20 anyways. > That's my proposal. The benefits I like to think are obvious. The > drawbacks are, as far as I can see, in tree size, which should be > minimal. Benefits of demo'ing for a minority (300 devs) must be balanced=20 against risk (adding profiles that portage can eat itself on, the=20 default virtual change doesn't address it, eapi incompatibility, vdb=20 changes )- wrong place to be deploying incompatibilites that paludis=20 introduces is into the production tree without appropriate=20 containment/protection. 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? Still have the sandbox for experimenting/demoing, but it minimizes the=20 potential borkage folks can hit by doing stupid things. ~harring --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEafrSvdBxRoA3VU0RAhKxAJwMzOcjUO9YR6mxWzvQltRpedqmmwCg4xiv g/KcCrvgHeWgqYEVZ8tasOY= =7axD -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- -- gentoo-dev@gentoo.org mailing list