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
pgpC2lhMLRD4q.pgp
Description: PGP signature
