Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

On Tue, May 16, 2006 at 05:47:42PM +0100, Ciaran McCreesh wrote:
> 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.

eapi=0 is what 2.1/2.05x supports.

Features are fine, but for gentoo backwards compatibility *is* a 
concern, as such dropping the bits that you dislike (but existing 
ebuilds rely on) is a no go.

> | dropping of all local vars during phase changes
>
> Again, we emulate Portage misfeatures only where it's found to be
> necessary.
See above...

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

See above.  Paludis (my view) is a rewrite of portage, rather then a 
reimplementation- as you've stated, dropping the stuff that you deem 
misfeatures.

This is fine, but portage *is* what gentoo is based uses now, and 
what all ebuilds have been written to, as such you need to either 
support the misfeatures or have a bullet proof transition plan to deal 
with the things you decided to carve out.

This is directly relevant because you now want to modify the 
gentoo-x86 repo to standards gentoo does not actually support.  Call 
it "dropping the misfeatures", but it's the reality of backwards 
compatibility (something that has been kicking portage devs in the 
nuts for years now).


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

Feature introduction is done via introducing support, then sitting on 
it for ~6 months to ensure folks don't get bit by it- notable 
exception was virtuals/* metapkg, although the buttload of bugs from 
it is a demonstration of *why* this route must be taken.

This is also why eapi came about- faster introduction of compatibility 
breaking changes.

Meanwhile, the precedent for changes to the tree (pkg manager related 
changes) is that of "don't break shit for users", introducing N parent 
inherit profiles into the tree still qualifies as a concern- as 
stated, you're after demoing capabilities, do it somewhere other then 
production data.


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

Snarky response aside, I read the src (note the env screwups I've 
pointed out, and the fact y'all don't support try eclass unified 
overlays), and your documentation- the point was that paludis can 
only be used for new installs, and you're locked to paludis as your 
pkg manager at that point without a translation script.

Trying to make it clear that paludis isn't something you try out for a 
bit, then revert back to portage- it's a full rebuild.  That seriously 
limits the usefulness of the requested profile.


> 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

Just because something is a viable alternative to portage doesn't 
mean the tree should be mutated to the alternative, especially when 
the alternative breaks standards that are in the tree already.

Call it "misfeatures of portage", reality is that y'all introduce one 
insidious potential for bugs in 22k ebuilds via the env changes.

Yes, paludis is a viable pkg manager- it's not viable to work with 
ebuilds written to portage (eapi=0) however because of those adhoc 
changes, at least for the userbase size gentoo currently sports.  If 
it were breaks affecting 100 folk, hey, shit happens, but it's not.

One thing I am curious about though, is how closely you've checked 
things are running properly- ebuilds have preserved their state in 
local vars saved in the env dump for well over 2 years, cutting that 
out on a whim for 22k ebuilds is kind of risky.  It'll show at unmerge 
time and for binpkgs...


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

We can't do anything about that idiocy.

That doesn't mean a profile should be added to the tree that portage 
is incapable of resolving properly however- simple example would be 
inheriting from two parents, one that's base arch agnostic defaults, 
other is arch specific modifications.

If that profile were used by portage, it would pick up *strictly* the 
base arch agnostic defaults- this isn't "you're using the wrong 
profile dumb ass", this is "only the left most path is actually 
recursed".  Again, this is why N profile inheritance isn't in portage- 
you cannot introduce it without backwards compatibility protection.  
Having the profile in the tree is an uneeded potential for bugs, yes 
it's obvious to a gentoo dev in seeing it when a bug is reported, but 
how many users know about the leftmost descent issue for portage?


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

See above.  Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me 
as "sillier bugs", strikes me as "we stamped it with our name, thus 
introducing subtle bugs into minor packages like perl".

And yes, that's actually a valid example- easy to spot via just a 
simple grepping of the tree (I suggest you do so).


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

Point is, the tree (you're own words) is not a playground, nor is it a 
demoscene- don't introduce the potential for screwup in the tree 
without a damn good reason.

Demo'ing capabilities doesn't qualify, do it in the overlay y'all 
have.


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

Figured as much, the problem is that you cannot convert a communal 
resource (gentoo-x86) to be paludis specific without the go ahead from 
the rest of the community.  The tree must not be changed ad hoc to 
match whatever pkg manager the commiter likes (this includes pkgcore).  
Standards...

Bluntly, you break compatibility with vdb/tree, paludis has no real 
future with gentoo beyond forking- requiring 100,000 users to 
reinstall because you don't want to do backwards compatibility is 
daft.

The original discussion was about adding a paludis profile (not 
"portage sucks"), getting back to it, paludis is incompatible with 
portage at the actual ebuild level- considering that, why should the 
tree be modified to add a profile that's just going to introduce 
further breakage?

~harring