Difference between pages "Welcome" and "Virtual Packages"

(Difference between pages)
 
(two first cases for virtuals)
 
Line 1: Line 1:
<div class="container" style="font-family: Open Sans; font-size: 14px; line-height: 20px;"><div class="row"><div class="col-xs-12 col-md-8 col-lg-8">
+
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.
{{Slideshow}}
+
</div><div class="col-xs-12 col-md-4 col-lg-4">
+
[http://distrowatch.com/table.php?distribution=funtoo '''Funtoo Linux'''] is a Linux-based operating system that is a variant of [http://en.wikipedia.org/wiki/Gentoo_Linux Gentoo Linux], led by [[User:Drobbins|Daniel Robbins]] (the creator and former Chief Architect of Gentoo) who serves as benevolent dictator for life (BDFL) of the project. ''Funtoo Linux is optimized for the best possible performance, supporting Intel Core i7, AMD FX Processors, and others.''  [[Subarches|See what we support.]] See [[#Distinctives|Distinctives]], below, for more information about what makes us special.
+
  
'''Other Funtoo Projects include''':
+
== Virtual packages, metapackages and package sets ==
*  '''[[Keychain]]''', an SSH/GPG agent front-end.
+
Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.
* '''[[Metro]]''', automated Funtoo build engine.
+
* '''[[Linux_Fundamentals,_Part_1|Learn Linux]]'''! [[Awk_by_Example,_Part_1|Awk]], [[Bash_by_Example,_Part_1|Bash]], [[Sed_by_Example,_Part_1|Sed]]  and more.
+
  
 +
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.
  
'''Ebuild pages recently updated:''' {{#ask: [[Category:Ebuilds]]
+
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.
| order=descending
+
| sort=Modification date
+
| format=list
+
| limit=10
+
| searchlabel=
+
}} [[Ebuilds|more...]]
+
  
'''Want to submit a screenshot? [http://forums.funtoo.org/index.php?/topic/180-screenshots/ See here.]'''
+
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.
</div></div><div class="row"><div class="col-xs-12">
+
{{Announce|[[Support Funtoo]] and help us grow! '''Donate $15 per month and get a free SSD-based [[Funtoo Hosting|Funtoo Virtual Container]].'''}}
+
</div></div><div class="row"><div class="col-xs-12 col-md-4 col-lg-4">
+
=== News ===
+
{{NewsList|3}}
+
[[News|View More News...]]
+
  
=== Expand the wiki! ===
+
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.
  
The [[:Help:Funtoo_Editing_Guidelines | How to 'wiki']] will help get you started on wiki editing. Have a look at [[Requested-Documents]] and [[:Category:Needs_Updates | pages that need to be updated.]]
+
== 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.
  
See [[:Category:Ebuilds|Ebuilds]] for a list of all ebuild pages, and [[Adding an Ebuild to the Wiki]] for information on how to add one.
+
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.
</div><div class="col-sm-12 col-xs-12 col-md-4 col-lg-4">
+
=== Distinctives ===
+
  
Funtoo Linux is a meta-distribution, which means it is built (fully automatically) with the functionality and optimizations that ''you'' want, not what some distro maintainer thought was best for you. Packages are installed directly from source code, thanks to the [http://en.wikipedia.org/wiki/Portage_(software) Portage ports system], inspired by the FreeBSD ports system, written in Python and with full advanced package management functionality.
+
== Common uses for virtual packages ==
 +
=== System components and services ===
 +
Example: ''virtual/service-manager''
  
''Benefits for desktops'': leaner, optimized, faster system. ''Additional benefits for servers'': enable only what you actually need to reduce attack surface, thus improving security.
+
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.
  
We use [http://en.wikipedia.org/wiki/Git_(software) Git] for all our development, and we also use Git to deliver our ports tree to you.
+
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.
  
In contrast to Gentoo Linux, we offer a number of innovations, including our extensive use of git, [[Funtoo 1.0 Profile|our profile system]], [[Package:Boot-Update|boot-update]] boot management tool, our incredibly flexible [[Funtoo Linux Networking|template-based networking scripts]], [[Metro Quick Start Tutorial|Metro]] distribution build system, support of Debian, RHEL and other kernels, [[Creating_Python-related_Ebuilds|enhanced Python support]], Portage mini-manifests, user-centric distribution model, and a large number of community infrastructure improvements.
+
=== Tools provided by multiple packages ===
</div><div class="col-sm-12 col-xs-12 col-md-4 col-lg-4">
+
Example: ''virtual/eject''
=== Getting Started ===
+
  
'''[[Funtoo Linux Installation|Install Funtoo Linux]]''' and get involved in our user community. Get to know fellow users on our '''[http://forums.funtoo.org forums]'''. Funtoo Linux has a very active [http://en.wikipedia.org/wiki/IRC IRC] community on [http://freenode.net Freenode] (in the <code>#funtoo</code> channel) and you are encouraged to hang out with us.
+
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).
  
'''[[Reporting Bugs|We welcome bug reports and suggestions]]'''.  Please report bugs to our '''[http://bugs.funtoo.org bug tracker]'''. We take all bugs seriously, and all work performed is tracked on our bug tracker, for purposes of transparency.
+
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.
 
+
'''{{CreateAccount}}''', which allows you to log in to the wiki, [http://forums.funtoo.org forums] and [https://bugs.funtoo.org bug tracker]. See the [[Funtoo Authentication FAQ|Auth FAQ]] for more info about account creation.
+
 
+
'''See our [[Funtoo Linux FAQ|FAQ]] for answers to common questions.'''
+
 
+
Other resources include [http://larrythecow.org larrythecow.org], the Gentoo blog aggregator, [http://kernel-seeds.org kernel-seeds.org], and [http://git.funtoo.org git.funtoo.org], our cgit repository browser.
+
</div></div></div>
+
 
+
__NOTITLE__
+
__NOEDITSECTION__
+
{{#subobject:|slideIndex=0|slideCaption=
+
<h4>h3nnn4n</h4>
+
 
+
Awesome WM / Conky / screenfetch
+
|slideImage=File:H3nnn4n.jpg}}
+
{{#subobject:|slideIndex=1|slideCaption=
+
<h4>Help us document the Gentoo Ecosystem!</h4>
+
From Enoch to Gentoo to Funtoo to ChromeOS, and beyond...
+
|slideImage=File:Ecosystem-snapshot.jpg|slideLink=Gentoo Ecosystem}}
+
{{#subobject:|slideIndex=2|slideCaption=
+
<h4>brushdemon</h4>
+
 
+
OpenBox / screenfetch
+
|slideImage=File:brushdemon.jpg}}
+
{{#subobject:|slideIndex=3|slideCaption=
+
<h4>drobbins</h4>
+
 
+
[[GNOME First Steps|GNOME 3.14]]  / [[Funtoo_Linux_FAQ#Do_you_support_systemd.3F|without systemd]] / Badgers optional
+
|slideImage=File:gnome3122.jpg|slideLink=GNOME First Steps}}
+
 
+
{{#subobject:|slideIndex=4|slideCaption=
+
<h4>spectromas</h4>
+
 
+
[[Package:Awesome_(Window_Manager)|Awesome WM]]
+
|slideImage=File:awesome.jpg|slideLink=Package:Awesome (Window Manager)}}
+
 
+
{{#seo:
+
|title=Funtoo Linux
+
|keywords=funtoo,linux,gentoo,Daniel Robbins
+
|description=Funtoo Linux is a Gentoo-based OS that uses a git-based Portage tree. Run by Daniel Robbins, creator of Gentoo.
+
}}
+

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:

  1. 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.
  2. 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.