On Sunday 06 March 2005 20:12, Stephen Bennett wrote: > On Sun, 2005-03-06 at 19:40 +0200, Dan Armak wrote: > > 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 idea is that a metapackage, unlike a normal ebuild, doesn't exist in > the installed package db, and its deps are always inspected when it > turns up in the depgraph. That means that you avoid the situation where > you merge package A, which depends on virtual/x11, and then pulls in > xorg-x11. Then, for whatever reason, you unmerge xorg, and virtual/x11 > is still in the vdb, so the next app you merge that deps on it will > break. That was explained in the -dev thread I linked; I probably should > add an explanation into the GLEP. OK. That would be fixed (for all ebuilds) by RDEPEND support on unmerge.
> > 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? > > Since the metapackage has some arbitrary DEPEND string that has to be > met, there's no reason why this couldn't require all packages reckoned > to be part of a set, rather than one of the packages reckoned to provide > a virtual. Yes, but you can already do this with an ebuild. The only difference is again the RDEPEND issues... Well, this should be mentioned in the GLEP IMO. BTW, the new functionality I think we really need for sets (which isn't specified in GLEP 21) is for the unmerge command to act on an entire set. E.g. to unmerge all of the (slotted) KDE 3.4 after installing 3.5. -- 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
pgpejR8LyfSLm.pgp
Description: PGP signature
