1 |
On Sunday 06 March 2005 20:12, Stephen Bennett wrote: |
2 |
> On Sun, 2005-03-06 at 19:40 +0200, Dan Armak wrote: |
3 |
> > It's a cool idea. What's missing in the proto-GLEP is an explanation of |
4 |
> > why you can't do this with a normal ebuild (that doesn't install any |
5 |
> > files), and need the new concept of metapackages. |
6 |
> |
7 |
> The idea is that a metapackage, unlike a normal ebuild, doesn't exist in |
8 |
> the installed package db, and its deps are always inspected when it |
9 |
> turns up in the depgraph. That means that you avoid the situation where |
10 |
> you merge package A, which depends on virtual/x11, and then pulls in |
11 |
> xorg-x11. Then, for whatever reason, you unmerge xorg, and virtual/x11 |
12 |
> is still in the vdb, so the next app you merge that deps on it will |
13 |
> break. That was explained in the -dev thread I linked; I probably should |
14 |
> add an explanation into the GLEP. |
15 |
OK. That would be fixed (for all ebuilds) by RDEPEND support on unmerge. |
16 |
|
17 |
> > Also, the GLEP says: "On a side note, this system of metapackages would |
18 |
> > provide an implementation of 'package sets' as proposed in GLEP 21 [2]_." |
19 |
> > |
20 |
> > I don't see how that would happen. A package set exists to install all of |
21 |
> > a list of packages, while a virtual/metapackage exists to install one of |
22 |
> > a list of (often mutually exclusive) packages. These are very different |
23 |
> > goals. How would metapackages help with sets any more than ordinary |
24 |
> > ebuilds already do? |
25 |
> |
26 |
> Since the metapackage has some arbitrary DEPEND string that has to be |
27 |
> met, there's no reason why this couldn't require all packages reckoned |
28 |
> to be part of a set, rather than one of the packages reckoned to provide |
29 |
> a virtual. |
30 |
Yes, but you can already do this with an ebuild. The only difference is again |
31 |
the RDEPEND issues... |
32 |
|
33 |
Well, this should be mentioned in the GLEP IMO. |
34 |
|
35 |
BTW, the new functionality I think we really need for sets (which isn't |
36 |
specified in GLEP 21) is for the unmerge command to act on an entire set. |
37 |
E.g. to unmerge all of the (slotted) KDE 3.4 after installing 3.5. |
38 |
|
39 |
-- |
40 |
Dan Armak |
41 |
Gentoo Linux developer (KDE) |
42 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
43 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |