Jump to: navigation, search

Virtual Packages

1,414 bytes added, 5 years ago
== Common uses for virtual packages ==
=== System components and services ===
Example: ''<code>virtual/service-manager''</code>
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.
=== Tools provided by multiple packages ===
Example: ''<code>virtual/eject''</code>
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).
=== Libraries with certain degree of ABI compatibility ===
Example: ''<code>virtual/libudev''</code>
This kind of virtuals is to allow switching between multiple providers of a library. However, virtual can only be used when the various providers provide ABI-compatible variants of the same library.
Virtual ebuild should have a separate version at least for every ABI version of the library. The ebuilds should have appropriate subslots and depend on respective subslots or versions of the provider that provide the library with necessary ABI. For example, <code>virtual/libfoo-1</code> depends on specific versions of libfoo providers that provide <code></code>, while <code>virtual/libfoo-2 </code> depends on versions providing <code></code>. This guarantees that the reverse dependencies of the virtual will be rebuilt when the underlying library is upgraded.
Example: "<code>virtual/linux-sources"</code>
This kind of virtual contains a list of linux kernel sources ebuilds, normally found in as <code>sys-kernel/*-sources</code>ebuilds in portage tree. A rationale behind this virtual is following:
Certain packages (such as 3-rd-party modules), during configuration, compilation or runtime expects that linux kernel sources exist on a target machine.
This virtual has the only aim of ensuring target machine already has kernel sources installed or it will make portage install a kernel prior to any package relying on kernel sources to be present. Technically, this virtual have some practical flaws, which are:
* a) it is very unlikely that user's boxes have no kernels installed. You can't use Funtoo without kernel, obviously. Checking for kernel might be improved in some other way.
* b) kernel virtual ebuild working with list of sources ebuilds in descending order. From first entry to the last. In case no kernel installed, attempting to merge package, which has <code>virtual/linux-sources</code> dependency portage will install <code>sys-kernel/*-sources</code> which is first entry in virtual. This is not handy, if you want to avoid certain ebuild. A solution to this is manual installation of kernel, for example <code> emerge vanilla-sources</code>.
* c) In case user trying to avoid using ebuild system for kernel installation, for example, by simple unpack of kernel sources tarball in desired place and compilation, packages that depend on <code>virtual/linux-sources</code> will make portage to perform steps described in above, see b).
A solution for c) described in (A virtual case part).

Navigation menu