Stephen Bennett wrote:
As those who hang around in the mysterious realms of Portage development
may know, there's some feeling around that the current system of virtual
packages has some serious limitations. The currently-proposed
alternative (as discussed previously, notably in
http://thread.gmane.org/gmane.linux.gentoo.devel/18922), involves a
system of metapackages. These would essentially consist of a
non-installable ebuild that consists entirely of a set of dependency
information. Once the dependencies for the metapackage are satisfied,
it's considered to be installed, and packages depending on it can go
ahead and be built.
This approach brings several advantages over the current system,
particularly:
- Allowing one version of a package to provide a different version of a
virtual, where these are necessary.
- Fixing the screwup with .51's virtual handling whereby gcc-2.95.x has
PROVIDE="sys-apps/texinfo", a package depends on >=texinfo-4.6, so
portage tries to install >=gcc-4.6.
- Provides, in one easily accessible place, a list of package that could
be used to satisfy the dependency. This has advantages for speed (no
searching the tree for PROVIDEs) and for user-friendliness.
Anyway, with portage development as it is now, this got brought up
again, and the current state of the GLEP can be found at
http://dev.gentoo.org/~spb/metapkg-glep.txt. Comments/suggestions/flames
welcome.
As long as you keep the PROVIDES line in the ebuild. Assuming repoman
does full tree check when commiting it can make sure that all packages
that PROVIDE virtual also exist in the metapackage. That would be my
only concern, people forgetting to add lines to the correct files :)
--
[email protected] mailing list
--
[email protected] mailing list
