1 |
On Wednesday 02 March 2005 00:15, Stephen Bennett wrote: |
2 |
> As those who hang around in the mysterious realms of Portage development |
3 |
> may know, there's some feeling around that the current system of virtual |
4 |
> packages has some serious limitations. The currently-proposed |
5 |
> alternative (as discussed previously, notably in |
6 |
> http://thread.gmane.org/gmane.linux.gentoo.devel/18922), involves a |
7 |
> system of metapackages. These would essentially consist of a |
8 |
> non-installable ebuild that consists entirely of a set of dependency |
9 |
> information. Once the dependencies for the metapackage are satisfied, |
10 |
> it's considered to be installed, and packages depending on it can go |
11 |
> ahead and be built. |
12 |
It's a cool idea. What's missing in the proto-GLEP is an explanation of why |
13 |
you can't do this with a normal ebuild (that doesn't install any files), and |
14 |
need the new concept of metapackages. |
15 |
|
16 |
The only reason I've found (IIRC it's described in the linked thread too) is |
17 |
this scenario: |
18 |
1. virtual/foo has DEPEND="|| ( pkgA pkgB )". |
19 |
2. User has pkgB-1.5 emerged. |
20 |
3. User emerges package depending on >=virtual/foo-2. |
21 |
4. pkgA-2.0 is pulled in, instead of upgrading pkgB to 2.0. |
22 |
|
23 |
There's also the question of portage not checking RDEPENDs when unmerging, so |
24 |
you can unmerge a dep (and things will break) but you can't unmerge a package |
25 |
providing a virtual (portage will catch that). But the correct solution here, |
26 |
if we're going to modify portage, is to add generic RDEPEND checking support |
27 |
to emerge unmerge... |
28 |
|
29 |
Am I missing another reason? Regardless, the reason for this should be in the |
30 |
GLEP. |
31 |
|
32 |
Also, the GLEP says: "On a side note, this system of metapackages would |
33 |
provide an implementation of 'package sets' as proposed in GLEP 21 [2]_." |
34 |
|
35 |
I don't see how that would happen. A package set exists to install all of a |
36 |
list of packages, while a virtual/metapackage exists to install one of a list |
37 |
of (often mutually exclusive) packages. These are very different goals. How |
38 |
would metapackages help with sets any more than ordinary ebuilds already do? |
39 |
|
40 |
Please enlighten me if I've totally missed your point. |
41 |
|
42 |
-- |
43 |
Dan Armak |
44 |
Gentoo Linux developer (KDE) |
45 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
46 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |