On Tue, 01 Mar 2005 22:15:51 +0000 Stephen Bennett <[EMAIL PROTECTED]> 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. -- [email protected] mailing list
