Re: [gentoo-dev] GLEP ??: Metapackages

[Thomas de Grenier de Latour <degrenier@easyconnect.fr>]

On Tue, 01 Mar 2005 22:15:51 +0000
Stephen Bennett <spb@gentoo.org> wrote:

> http://dev.gentoo.org/~spb/metapkg-glep.txt.
> Comments/suggestions/flames welcome.

A first minor drawback i see is that it complicates things for
people who use overlay ebuilds. For instance, making your own
kernel sources ebuilds right now is has simple as inheriting an
eclass, which will give them the right PROVIDES line. But with
this glep, you will also have to overlay the metapkg and add
declare your sources in it, and then manually maintain it to keep
in sync with the one in the tree (cause you don't want to break
other official kernel sources packages). In that respect, the
current virtuals system is much more confortable, because ebuilds
are really standalone, not inter-dependent. 


An imho more serious drawback is that there is, in this proposal,
no way for a user to explicitly declare what implementation of a
virtual he prefers. As i've already said in the previous thread, i
think this /etc/portage/profiles/virtuals was a very good thing,
and there is no such user prefs file with this glep. I'll try to
explain why it bothers me with an example:

 - metaM depends on "|| ( pkgA pkgB pkgC )"
 - pkgD depends on metaM
 - pkgE depends on pkgC

If user "emerge pkgD" and then "emerge pkgE", he will have both
pkgA and pkgC installed as deps.
If at the contrary he "emerge pkgE" before "emerge pkgD", he will
only have pkgC installed to satisfy both deps.
If he then wants to clone his system on an other station by doing
an "emerge $(< world.orig)", he may have only pkgC or both pkgA
and pkgC, depending on how the world file is ordered.

And if his prefered implementation of metaM is pkgB anyway, he
would better emerge it explicitly soon enough, before anything
else that depends on metaM. Actually, a picky user should dig
through all the virtuals right after his installation and
explicitly emerge all the packages for which he has a preference,
whereas with the current virtuals implementation he can state that
in a config file let emerge deal with it when the virtuals are
actually depended on.

So, in short, dropping the "virtuals" file is a regression imho,
because it makes portage behavior less deterministic; it will
depend more on the history of user actions (calls to emerge), and
less on user prefs, making it harder to understand and control.

Oh, and btw, this lack of "virtuals" prefs file may also be a
problem for official profiles. For instance, I see that "base"
currently has "virtual/jdk  dev-java/blackdown-jdk", whereas ppc
profiles override that with "virtual/jdk  dev-java/ibm-jdk-bin".
And i guess they have good reasons to do so... How will that be
handled with metapkgs? By having numerous "arch? ( ... )" in the
DEPEND string? 

-- 
TGL.
--
gentoo-dev@gentoo.org mailing list