1 |
On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote: |
2 |
> If noone has any strong reasonable objections, I'd like to add a |
3 |
> Paludis profile to the tree. This would use Paludis as the default |
4 |
> provider for virtual/portage (which is a less than ideal name, but that |
5 |
> is another discussion entirely), and provide ebuild devs with a place |
6 |
> where they can try out some of our profile enhancements should they |
7 |
> want to. It is worth noting on the last point that most of these are |
8 |
|
9 |
> Comments? |
10 |
|
11 |
Maybe I'm daft, but why does this need to be demoed in the live tree? |
12 |
Use an overlay (y'all have one already anyways). Reasons why this is |
13 |
a bit daft- |
14 |
|
15 |
1) changes to the eapi=0 ebuild standard; renaming of vars |
16 |
(PORTAGE_* -> PALUDIS_* namely), dropping of all local vars during |
17 |
phase changes (since y'all lack ebuild, it'll rear it's head mainly |
18 |
during unmerge), effective dropping of config phase (another place |
19 |
it would rear it's head)... Mind you that's from a quick read through |
20 |
of your ebuild env reimplementation, stated the issues already and |
21 |
they still remain- incomplete support for the standard is one thing, |
22 |
changing it is another (y'all are doing the latter). |
23 |
|
24 |
2) N profile inheritance- the parents change (N entries instead of |
25 |
one) needs to be protected so that specific profile is only usable by |
26 |
a package manager (whether portage, pkgcore or paludis) that actually |
27 |
does N parent inheritance. This is why N profile inheritance has |
28 |
never been added to portage (it's honestly a one line change in |
29 |
portage)- the change must not be introduced without protection, |
30 |
else the user's system set can become drastically reduced. It's not |
31 |
an easily addressable problem (all solutions sans a new profile |
32 |
directory leave open the potential for users to get bit), ignoring it |
33 |
is a no go. Yes, you're after demoing capabilities- problem is that |
34 |
it's exposing potential horkage in a production tree, wrong place to |
35 |
be demoing. |
36 |
|
37 |
3) vdb CONTENTS change of dev/fif to misc. It's dumb, but that change |
38 |
renders vdb entries incompatible- iow, proper usage/conversion to |
39 |
paludis requires a new installation (or translation script, both |
40 |
to/from portage). |
41 |
|
42 |
So... short version, introduction of the profile allows for curious |
43 |
users to get bit in the ass by intentional dropping of compatibility |
44 |
(profile level changes are one thing, changing the ebuild standard is |
45 |
another). In light of that, why should it be demoed in the tree where |
46 |
the only use of it is to bootstrap a new installation? Just overlay |
47 |
it, y'all should be maintaining an overlay fixing ebuild incompatibilities |
48 |
anyways. |
49 |
|
50 |
> That's my proposal. The benefits I like to think are obvious. The |
51 |
> drawbacks are, as far as I can see, in tree size, which should be |
52 |
> minimal. |
53 |
|
54 |
Benefits of demo'ing for a minority (300 devs) must be balanced |
55 |
against risk (adding profiles that portage can eat itself on, the |
56 |
default virtual change doesn't address it, eapi incompatibility, vdb |
57 |
changes )- wrong place to be deploying incompatibilites that paludis |
58 |
introduces is into the production tree without appropriate |
59 |
containment/protection. |
60 |
|
61 |
The gain of the profile is that you can do a few new tricks for folks |
62 |
doing boostrapping experiments- why not just introduce an ebuild that |
63 |
sets up the new profile in a temp overlay? |
64 |
|
65 |
Still have the sandbox for experimenting/demoing, but it minimizes the |
66 |
potential borkage folks can hit by doing stupid things. |
67 |
|
68 |
~harring |