| 1 |
As those who hang around in the mysterious realms of Portage development |
| 2 |
may know, there's some feeling around that the current system of virtual |
| 3 |
packages has some serious limitations. The currently-proposed |
| 4 |
alternative (as discussed previously, notably in |
| 5 |
http://thread.gmane.org/gmane.linux.gentoo.devel/18922), involves a |
| 6 |
system of metapackages. These would essentially consist of a |
| 7 |
non-installable ebuild that consists entirely of a set of dependency |
| 8 |
information. Once the dependencies for the metapackage are satisfied, |
| 9 |
it's considered to be installed, and packages depending on it can go |
| 10 |
ahead and be built. |
| 11 |
|
| 12 |
This approach brings several advantages over the current system, |
| 13 |
particularly: |
| 14 |
- Allowing one version of a package to provide a different version of a |
| 15 |
virtual, where these are necessary. |
| 16 |
- Fixing the screwup with .51's virtual handling whereby gcc-2.95.x has |
| 17 |
PROVIDE="sys-apps/texinfo", a package depends on >=texinfo-4.6, so |
| 18 |
portage tries to install >=gcc-4.6. |
| 19 |
- Provides, in one easily accessible place, a list of package that could |
| 20 |
be used to satisfy the dependency. This has advantages for speed (no |
| 21 |
searching the tree for PROVIDEs) and for user-friendliness. |
| 22 |
|
| 23 |
Anyway, with portage development as it is now, this got brought up |
| 24 |
again, and the current state of the GLEP can be found at |
| 25 |
http://dev.gentoo.org/~spb/metapkg-glep.txt. Comments/suggestions/flames |
| 26 |
welcome. |
| 27 |
|
| 28 |
-- |
| 29 |
gentoo-dev@g.o mailing list |
Archives