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

[Stephen Bennett <spb@gentoo.org>]

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.

> 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...

Allegedly the new dep resolver that's being worked on should handle
that... not sure if it'll get into the next portage release though. But
agreed, it is needed, and from what I've been given to understand should
handle this situation properly without too much extra effort.

> 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. 

--
gentoo-dev@gentoo.org mailing list