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. | 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@gentoo.org mailing list
