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
pgprMxLIVTnTm.pgp
Description: PGP signature
