Difference between pages "News:New Media Mix-ins" and "Virtual Packages"

Revision as of 13:31, February 7, 2015

Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.

Virtual packages, metapackages and package sets

Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.

Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.

Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.

Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.

Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.

When virtual packages can be used?

For virtual package ebuild to work correctly, the two following requirements must be met:

the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.

Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.

Common uses for virtual packages

System components and services

Example: virtual/service-manager

One of the common uses for virtuals is to define abstract system services. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.

The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.

Tools provided by multiple packages

Example: virtual/eject

This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).

While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.

@@ Line 1: / Line 1: @@
-{{News
+Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.
-|Summary=Funtoo Linux now has new media mix-ins. Learn about them and how to use them.
-|News Format=Extended
-|News Category=General
-|Author=Drobbins
-|Publication Status=Published
-|Publication Date=2015/01/11
-}}
-Hello everyone,
-Funtoo Linux has amazing support for all different kinds of audio, video and graphics formats, as well as media devices that can be enabled via USE flags -- but let's face it  -- with all this flexibility has come a certain amount of complexity in enabling all the USE flags you need for a particular application. I've tried to address this by [[Funtoo Profiles|enhancing the profile system]] to include flavors and mix-ins, and creating a {{c|media}} mix-in that enables stuff that a lot of people will want, which is auto-enabled in the {{c|desktop}} and {{c|workstation}} profile. But I always knew that this, while an improvement, was not the final word on media support in Funtoo Linux, and that we needed to do more work here.
+== Virtual packages, metapackages and package sets ==
+Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.
-Recently, thanks to assistance from [[User:Mgorny|Michał Górny]], we have been able to implement my design for second-generation media support to Funtoo Linux! Here's how it works. Rather than have a single mix-in called "media", we now have finer-grained categories, and the existing {{c|media}} mix-in has been upgraded to pull in a subset of these categories. Let's look at all the new mix-ins:
+Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.
-=== Media Device Mix-ins ===
+Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.
-Media device mix-ins have been created to support media devices, including external and portable devices, and associated low-level hardware support and hardware-focused codecs. Media devices have been categorized into audio and video categories, and consumer and professional categories. "Consumer" devices are those devices that regular desktop users might typically use, while "professional" devices are those that professionals, hobbyists or enthusiasts would typically use. Here are the new mix-ins for media devices:
+Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.
-{{TableStart}}
+Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.
-<tr><th class="active">Mix-in</th><th class="active">Description</th></tr>
-<tr><td>{{c|mediadevice-base}}</td><td>Common, universally-supported media devices, like IEEE-1394 (Firewire), CDDA, CDIO. Other mediadevice mix-ins have this as a parent.</td></tr>
-<tr><td>{{c|mediadevice-audio-consumer}}</td><td>Consumer audio devices, such as personal portable media players (iOS, iPod, etc.)</td></tr>
-<tr><td>{{c|mediadevice-audio-pro}}</td><td>Pro audio support, such as JACK.</td></tr>
-<tr><td>{{c|mediadevice-video-consumer}}</td><td>Consumer video support, such as DVD, Blu Ray, V4L</td></tr>
-<tr><td>{{c|mediadevice-video-pro}}</td><td>Pro video support, such as dv, dc1394.</td></tr>
-{{TableEnd}}
-=== Media Format Mix-ins ===
+== When virtual packages can be used? ==
+For virtual package ebuild to work correctly, the two following requirements must be met:
+# the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
+# Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.
-Media format mix-ins have been created to support media formats for reading, writing, encoding and decoding images, audio and video. They have been organized into a "common" collection, for popular formats, and an "extra" collection, which is intended to include "everything else". Let's look at the new mix-ins:
+Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.
-{{TableStart}}
+== Common uses for virtual packages ==
-<tr><th class="active">Mix-in</th><th class="active">Description</th></tr>
+=== System components and services ===
-<tr><td>{{c|mediaformat-video-common}}</td><td>Common (ie. popular) video formats.</td></tr>
+Example: ''virtual/service-manager''
-<tr><td>{{c|mediaformat-video-extra}}</td><td>More esoteric video formats.</td></tr>
-<tr><td>{{c|mediaformat-audio-common}}</td><td>Common (ie. popular) audio formats.</td></tr>
-<tr><td>{{c|mediaformat-audio-extra}}</td><td>More esoteric audio formats.</td></tr>
-<tr><td>{{c|mediaformat-gfx-common}}</td><td>Common (ie. popular) graphics formats.</td></tr>
-<tr><td>{{c|mediaformat-gfx-extra}}</td><td>More esoteric graphics formats.</td></tr>
-{{TableEnd}}
-=== How to Use Them ===
+One of the common uses for virtuals is to define abstract ''system services''. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.
-Our existing {{c|media}} mix-in still exists, and is still pulled in by the {{c|desktop}} and {{c|workstation}} flavors automatically. It now includes the following parent mix-ins:
+The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.
-* {{c|mediadevice-audio-consumer}}
+=== Tools provided by multiple packages ===
-* {{c|mediadevice-video-consumer}}
+Example: ''virtual/eject''
-* {{c|mediaformat-audio-common}}
-* {{c|mediaformat-gfx-common}}
-* {{c|mediaformat-video-common}}
-In addition, there is a new {{c|media-pro}} mix-in which needs to be enabled manually, which pulls in the following mix-ins:
+This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).
-* {{c|mediadevice-audio-pro}}
+While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.
-* {{c|mediadevice-video-pro}}
-So typically, you would enable the {{c|desktop}} or {{c|workstation}} flavor, and if you need professional hardware support, you'd also enable the {{c|media-pro}} mix-in. If you needed any additional media formats support, you could enable one or more of the {{c|mediaformat-*-extra}} mix-ins to add the formats you needed. Of course, it's possible to enable only the specific mix-ins you need, and also complement these mix-ins with specific USE variable settings you might require.
-If you're new to Funtoo Profiles, see the [[Funtoo Profiles]] pages for more information on how they work.
-=== Conclusion ===
-Going forward, these mix-ins can be maintained to include new USE flags that are created, providing an easy way for people to enable the features they need without looking through long lists of USE variables. I hope you like the new system!
-{{NewsFooter}}