Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferringb@×××××.com>
wrote:
| 1) changes to the eapi=0 ebuild standard; renaming of vars 
| (PORTAGE_* -> PALUDIS_* namely)

What eapi=0 standard? We emulate Portage internals where it's found to
be necessary, and don't otherwise.

| dropping of all local vars during phase changes

Again, we emulate Portage misfeatures only where it's found to be
necessary.

| effective dropping of config phase

Uh, no. Config's on the 0.4 list. We're just prioritising things that
we actually need.

| 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).

What standard? Are you trying to say that Paludis should emulate
Portage's bugs, because the standard is "exactly what Portage does"?

| 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.  

Uh, no. Any user who isn't using a package manager capable of multiple
inherits shouldn't use a multiple inherits profile. There's plenty of
precedent of intro

| Yes, you're after demoing capabilities- problem is that 
| it's exposing potential horkage in a production tree, wrong place to 
| be demoing.

Heh. "potential horkage". Yes, if a user sets their profile
incorrectly, things break. That's the case currently too. 

| 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).

Had you bothered to read the documentation, you'd know that we don't
claim nor desire VDB compatibility with Portage, and don't encourage
installs onto the same ROOT.

We also don't emulate Portage's broken handling of merging directories
onto symlinks, which means that uninstalling via emerge sometimes
leaves behind cruft.

| 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.

Because Paludis is now a viable alternative to Portage and can be used
to install and maintain a real system. We already support enough of the
"ebuild standard" and emulate enough of Portage's bugs to install
system + X + KDE + Gnome + a whole load of random stuff that people
actually use.

| > 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

Uh, a user changing to any incorrect profile will screw up their
system. Ever tried using an amd64 profile on x86?

| eapi incompatibility

You mean "not emulating some of Portage's sillier bugs that very few
things rely upon anyway", right?

| vdb changes )- wrong place to be deploying incompatibilites that paludis 
| introduces is into the production tree without appropriate 
| containment/protection.

Uh, VDB isn't part of the tree. Nor does it introduce any breakages for
existing users, except those who do something especially dumb. Even if
a user *does* change their profile to a Paludis profile, it won't cause
Portage to explode in such a way that switching profiles back won't fix
it.

| 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?

No, the gain of the profile is that it prepares the way for people to
move onto a package manager that doesn't suck.

Now, if you were to object to, say, -scm versions in the main tree,
whose very existence causes Portage to crap itself messily and die, you
might have a point. But adding a profile only screws things up for
users who manually switch to it, and it only screws them up temporarily
and fairly cleanly.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@g.o mailing list