| 1 |
On Tue, 01 Mar 2005 22:15:51 +0000 |
| 2 |
Stephen Bennett <spb@g.o> wrote: |
| 3 |
|
| 4 |
> http://dev.gentoo.org/~spb/metapkg-glep.txt. |
| 5 |
> Comments/suggestions/flames welcome. |
| 6 |
|
| 7 |
A first minor drawback i see is that it complicates things for |
| 8 |
people who use overlay ebuilds. For instance, making your own |
| 9 |
kernel sources ebuilds right now is has simple as inheriting an |
| 10 |
eclass, which will give them the right PROVIDES line. But with |
| 11 |
this glep, you will also have to overlay the metapkg and add |
| 12 |
declare your sources in it, and then manually maintain it to keep |
| 13 |
in sync with the one in the tree (cause you don't want to break |
| 14 |
other official kernel sources packages). In that respect, the |
| 15 |
current virtuals system is much more confortable, because ebuilds |
| 16 |
are really standalone, not inter-dependent. |
| 17 |
|
| 18 |
|
| 19 |
An imho more serious drawback is that there is, in this proposal, |
| 20 |
no way for a user to explicitly declare what implementation of a |
| 21 |
virtual he prefers. As i've already said in the previous thread, i |
| 22 |
think this /etc/portage/profiles/virtuals was a very good thing, |
| 23 |
and there is no such user prefs file with this glep. I'll try to |
| 24 |
explain why it bothers me with an example: |
| 25 |
|
| 26 |
- metaM depends on "|| ( pkgA pkgB pkgC )" |
| 27 |
- pkgD depends on metaM |
| 28 |
- pkgE depends on pkgC |
| 29 |
|
| 30 |
If user "emerge pkgD" and then "emerge pkgE", he will have both |
| 31 |
pkgA and pkgC installed as deps. |
| 32 |
If at the contrary he "emerge pkgE" before "emerge pkgD", he will |
| 33 |
only have pkgC installed to satisfy both deps. |
| 34 |
If he then wants to clone his system on an other station by doing |
| 35 |
an "emerge $(< world.orig)", he may have only pkgC or both pkgA |
| 36 |
and pkgC, depending on how the world file is ordered. |
| 37 |
|
| 38 |
And if his prefered implementation of metaM is pkgB anyway, he |
| 39 |
would better emerge it explicitly soon enough, before anything |
| 40 |
else that depends on metaM. Actually, a picky user should dig |
| 41 |
through all the virtuals right after his installation and |
| 42 |
explicitly emerge all the packages for which he has a preference, |
| 43 |
whereas with the current virtuals implementation he can state that |
| 44 |
in a config file let emerge deal with it when the virtuals are |
| 45 |
actually depended on. |
| 46 |
|
| 47 |
So, in short, dropping the "virtuals" file is a regression imho, |
| 48 |
because it makes portage behavior less deterministic; it will |
| 49 |
depend more on the history of user actions (calls to emerge), and |
| 50 |
less on user prefs, making it harder to understand and control. |
| 51 |
|
| 52 |
Oh, and btw, this lack of "virtuals" prefs file may also be a |
| 53 |
problem for official profiles. For instance, I see that "base" |
| 54 |
currently has "virtual/jdk dev-java/blackdown-jdk", whereas ppc |
| 55 |
profiles override that with "virtual/jdk dev-java/ibm-jdk-bin". |
| 56 |
And i guess they have good reasons to do so... How will that be |
| 57 |
handled with metapkgs? By having numerous "arch? ( ... )" in the |
| 58 |
DEPEND string? |
| 59 |
|
| 60 |
-- |
| 61 |
TGL. |
| 62 |
-- |
| 63 |
gentoo-dev@g.o mailing list |
Archives