On Tue, May 16, 2006 at 05:47:42PM +0100, Ciaran McCreesh wrote: > On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <[EMAIL PROTECTED]> > 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
pgp0Qy0Vcaxbx.pgp
Description: PGP signature
