Get Gentoo!

GLEP 37: Virtuals Deprecation

Author Jason Stubbs <[email protected]>
Type Standards Track
Status Deferred
Version 1
Created 2005-04-30
Last modified 2024-07-16
Posting history 2005-04-30, 2006-09-05
GLEP source glep-0037.rst

Status

What has been implemented so far diverges somewhat from what is stated in this GLEP. As such, this GLEP (in its current form) has been marked "deferred".

Credits

Most ideas in this GLEP came out of discussion with Thomas de Grenier de Latour. Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided help in fleshing out the idea.

Abstract

This GLEP covers the pitfalls of the current virtuals system, the benefits of using regular ebuilds to serve the purpose of virtuals and what needs to be supported to make it viable.

Motivation

The current virtuals system is decentralized; that is there is no way to find information about a specific virtual other than to scan all packages for what they provide. There is also no way to tell whether an atom is a virtual or not - yes, the "virtual/" prefix could have been used but it isn't which has led to its abuse.

What this means is that portage must scan all installed packages for the virtuals they provide, that profiles must provide a default for every single virtual that portage might encounter and that every single atom that portage processes must be checked against the list of virtuals. Needless to say that this causes quite a performance decrease.

The current virtuals system also has some other major shortcomings. The most well known case is virtual/jdk and kaffe. Kaffe-1.1.4 implements the Java 1.4 API but can not satisfy a package that requires >=virtual/jdk-1.4 because kaffe's versioning scheme differs. (ED: Need to add some more here. ;)

Specification

This GLEP recommends that virtuals become no different to regular packages. Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS, IUSE and RDEPEND metadata. An example would be something like this:

DESCRIPTION="Java Development Kit 1.4"
KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
RDEPEND="|| (
             =dev-java/blackdown-jdk-1.4*
             =dev-java/ibm-jdk-bin-1.4*
             =dev-java/jrockit-jdk-bin-1.4*
             =dev-java/kaffe-1.1.4*
             =dev-java/sun-jdk-1.4*
            )"
IUSE=""

However, there are some issues that have been brought up with doing this.

Consistency

Presently, it is very easy to remove packages even if others are dependent on them, which can lead to broken emerges when packages rely on indirect dependencies. For example, if kdelibs is merged bringing in qt and then qt is unmerged, attempting to merge kdebase will likely fail. This becomes a much bigger problem with virtuals as packages because the dependencies are always indirect.

The resolution for this issue will be to add full dependency tracking and verification to portage. The details of how it will be done are outside the scope of this GLEP, but essentially this means that portage will need to be forced to unmerge a package that is depended on by another and will also be able to scan and fix any broken dependencies.

Overrides

Profiles currently specify the default provider of each virtual and users are able to override these defaults using /etc/portage/profile/virtuals. If virtuals are replaced by regular packages and thus able to have arbitrarily complex DEPENDs, the current method of overriding default virtuals can not be extended to support this.

Before looking at a solution, lets look at how the current system works. When portage initializes, it searches installed packages for available virtuals. It then searches profiles and user overrides and adds them to the available providers list and/or changes the order of the providers so that overrides are listed earlier. Portage then expands any virtual atom it finds into an OR list using the order decided upon at initialization.

To keep this behaviour available, this GLEP proposes a new file named package.prefer. In its basic form, this is just a list of package names ordered by preference. Portage would use it by reordering the atoms of any OR list it processes to fit the order given by package.prefer. For example, if package.prefer contained "dev-java/kaffe" then:

|| (
    dev-java/blackdown-jdk
    dev-java/sun-jdk
    dev-java/kaffe
   )

would be processed as:

|| (
    dev-java/kaffe
    dev-java/blackdown-jdk
    dev-java/sun-jdk
   )

In its basic form, package.prefer already covers profile and user overrides. However, this GLEP proposes that any type of atom be usable. This will be accomplished by checking for intersections of the atoms in the OR list and atoms in the preferred list. When an intersection is found, both atoms would be specified in a sublist, which would then be treated as a ranged dep. For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:

|| (
    >=dev-java/blackdown-jdk-1.3
    >=dev-java/sun-jdk-1.3
   )

would be processed as:

|| (
    (
      <=dev-java/sun-jdk-1.4
      >=dev-java/sun-jdk-1.3
    )
    >=dev-java/blackdown-jdk-1.3
    >=dev-java/sun-jdk-1.3
   )

Ranged deps are outside of the scope of this GLEP.

Rationale

The number one advantage is that it offers more power to both the user and the developer. Flexibility of virtuals is far greater in this scheme and fulfills requirements that exist already. It also means that the maintainers of profiles will not need to list a default for every virtual. The user benefits by being able to easily gather a list of providers of a virtual as well as their control being extended to allow selection where there is a choice within any package.

Portage code also benefits from this scheme as virtuals will no longer require special handling or dual implementations of essentially the same feature, for example USE-based PROVIDEs. This scheme is also much easier to optimize which will benefit the processing of all packages. It also means that any additions to the DEPEND vocabulary become available for use in the definitions of virtuals.

Backwards Compatibility

Compatibility will begin by making 2.0.51.20 treat unknown virtuals like regular packages. When the tree is stripped of PROVIDEs and "virtuals" override files, the only virtuals that these portages will use are those that the user has specified and those gleaned from installed packages. Any unknown virtual will be treated like a regular package and looked for in the tree.

The next major version of portage (2.1.0) will support consistency checking. The only remaining issue is that of user overrides. The old method will work even with new style virtuals. The only catch is that complex virtuals - that is virtuals that will install more than one package - may not be overridable satisfactorally.

Dropping of support of current style virtuals is planned for the following major version of portage (2.2.0). When the time comes to release it, scripts will be written to create packages from the existing virtuals system as well as to create appropriate package.prefer overrides within the profiles.