On Wednesday 02 March 2005 00:15, Stephen Bennett wrote:
> As those who hang around in the mysterious realms of Portage development
> may know, there's some feeling around that the current system of virtual
> packages has some serious limitations. The currently-proposed
> alternative (as discussed previously, notably in
> http://thread.gmane.org/gmane.linux.gentoo.devel/18922), involves a
> system of metapackages. These would essentially consist of a
> non-installable ebuild that consists entirely of a set of dependency
> information. Once the dependencies for the metapackage are satisfied,
> it's considered to be installed, and packages depending on it can go
> ahead and be built.
It's a cool idea. What's missing in the proto-GLEP is an explanation of why 
you can't do this with a normal ebuild (that doesn't install any files), and 
need the new concept of metapackages.

The only reason I've found (IIRC it's described in the linked thread too) is 
this scenario:
1. virtual/foo has DEPEND="|| ( pkgA pkgB )".
2. User has pkgB-1.5 emerged.
3. User emerges package depending on >=virtual/foo-2.
4. pkgA-2.0 is pulled in, instead of upgrading pkgB to 2.0.

There's also the question of portage not checking RDEPENDs when unmerging, so 
you can unmerge a dep (and things will break) but you can't unmerge a package 
providing a virtual (portage will catch that). But the correct solution here, 
if we're going to modify portage, is to add generic RDEPEND checking support 
to emerge unmerge...

Am I missing another reason? Regardless, the reason for this should be in the 
GLEP.

Also, the GLEP says: "On a side note, this system of metapackages would 
provide an implementation of 'package sets' as proposed in GLEP 21 [2]_."

I don't see how that would happen. A package set exists to install all of a 
list of packages, while a virtual/metapackage exists to install one of a list 
of (often mutually exclusive) packages. These are very different goals. How 
would metapackages help with sets any more than ordinary ebuilds already do?

Please enlighten me if I've totally missed your point.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951