Re: [gentoo-dev] Paludis and Profiles

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3511 bytes --]

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?  
Use an overlay (y'all have one already anyways).  Reasons why this is 
a bit daft-

1) changes to the eapi=0 ebuild standard; renaming of vars 
(PORTAGE_* -> PALUDIS_* namely), dropping of all local vars during 
phase changes (since y'all lack ebuild, it'll rear it's head mainly 
during unmerge), effective dropping of config phase (another place 
it would rear it's head)... Mind you that's from a quick read through 
of your ebuild env reimplementation, stated the issues already and 
they still remain- incomplete support for the standard is one thing, 
changing it is another (y'all are doing the latter).

2) N profile inheritance- the parents change (N entries instead of 
one) needs to be protected so that specific profile is only usable by 
a package manager (whether portage, pkgcore or paludis) that actually 
does N parent inheritance.  This is why N profile inheritance has 
never been added to portage (it's honestly a one line change in 
portage)- the change must not be introduced without protection, 
else the user's system set can become drastically reduced.  It's not 
an easily addressable problem (all solutions sans a new profile 
directory leave open the potential for users to get bit), ignoring it 
is a no go.  Yes, you're after demoing capabilities- problem is that 
it's exposing potential horkage in a production tree, wrong place to 
be demoing.

3) vdb CONTENTS change of dev/fif to misc.  It's dumb, but that change 
renders vdb entries incompatible- iow, proper usage/conversion to 
paludis requires a new installation (or translation script, both 
to/from portage).

So... short version, introduction of the profile allows for curious 
users to get bit in the ass by intentional dropping of compatibility 
(profile level changes are one thing, changing the ebuild standard is 
another).  In light of that, why should it be demoed in the tree where 
the only use of it is to bootstrap a new installation?  Just overlay 
it, y'all should be maintaining an overlay fixing ebuild incompatibilities 
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 
against risk (adding profiles that portage can eat itself on, the 
default virtual change doesn't address it, eapi incompatibility, vdb 
changes )- wrong place to be deploying incompatibilites that paludis 
introduces is into the production tree without appropriate 
containment/protection.

The gain of the profile is that you can do a few new tricks for folks 
doing boostrapping experiments- why not just introduce an ebuild that 
sets up the new profile in a temp overlay?

Still have the sandbox for experimenting/demoing, but it minimizes the 
potential borkage folks can hit by doing stupid things.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]