Difference between pages "Install/fr/Kernel" and "Virtual Packages"

< Install‎ | fr(Difference between pages)
(Mise en place du noyau)
 
(two first cases for virtuals)
 
Line 1: Line 1:
=== Configuration et mise en place du noyau ===
+
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.
  
Aucun système Funtoo Linux ne peut fonctionner sans noyau. C'est le cœur du système, son moteur. Le chargeur d'amorçage interpelle ce dernier lors du démarrage. Le noyau sert d'interface entre les composants matériels et il permet l'exécution des différentes applications installées.
+
== 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.
  
Le noyau se doit d'être convenablement configuré afin de prendre en charge les unités de disque, les systèmes de fichiers, les cartes réseau, etc... Les utilisateurs expérimentés de Linux ont la possibilité de choisir un noyau à installer, le configurer et le mettre en place. En fait, c'est la façon traditionnelle d'installer un noyau quand on met en place un système bâti à partir de sources, un système tel Funtoo Linux.
+
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.
  
Funtoo Linux a pris en considération les utilisateurs moins expérimentés, voire débutants. C'est pourquoi Funtoo Linux met à la disposition de tous un noyau de type universel. Il s'agit d'un paquet constitué de «ebuilds» qui génèrent automatiquement les modules et le fichier «initramfs» garantissant ainsi un démarrage sans faille et un système capable de conjuguer avec tous les composants matériels. Voyons comment réaliser ceci en toute simplicité et le plus facilement possible.
+
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.
  
==== Les ensembles de paquets ====
+
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.
  
Nous avons abordé le concept des ensembles de paquets à la section[[Install/fr#Introduction_.C3.A0_Portage| Introduction à Portage]]. En plus de <code>world</code>, il y a aussi <code>system</code>. Cela nous permet donc de mettre le système à jour dans son entièreté avec <code>world</code> ou simplement une partie de celui-ci avec <code>system</code>. Ce dernier ensemble ne regroupe que les paquets formant le système de base.
+
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.
  
Le concept des ensembles de paquets ne s'arrête pas là. Nous pouvons l'étendre à d'autres paquets en créant d'autres entités du même genre. Si nous voulons que le noyau ne soit pas mis à jour en même temps que tout le système, nous créons un ensemble que nous nommerons <code>kernel</code>. Le nom n'est pas arbitraire.
+
== 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.
  
==== L'ensemble Kernel ====
+
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.
  
Pour créer cet ensemble, nous exécutons les commandes suivantes:
+
== Common uses for virtual packages ==
 +
=== System components and services ===
 +
Example: ''virtual/service-manager''
  
<console>
+
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.
(chroot) # ##i##mkdir /etc/portage/sets
+
(chroot) # ##i##echo sys-kernel/debian-sources > /etc/portage/sets/kernel
+
</console>
+
  
Maintenant indiquons à Portage que nous voulons créer un noyau «universel» et le fichier <code>initramfs</code>. Nous allons installer le noyau <code>debian-sources</code>. Afin que Portage construise le fichier <code>initramfs</code> en même temps qu'il bâtit le noyau, nous utilisons un USE flag conçu à cet effet. Il se nomme <code>binary</code>.
+
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.
  
<console>
+
=== Tools provided by multiple packages ===
(chroot) # ##i##install -d /etc/portage/package.use
+
Example: ''virtual/eject''
(chroot) # ##i##echo "sys-kernel/debian-sources binary" >> /etc/portage/package.use/kernel
+
</console>
+
  
{{Note|Nous avons créé un répertoire <code>package.use</code> dans lequel nous avons déposé un fichier contenant le nom du paquet et son USE flag. Nous aurions pu le faire directement dans un fichier du même nom que le répertoire. Voir le manuel <code>man portage</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).
  
Les USE flags sont des indicateurs qui nous donnent la possibilité de configurer les options de compilation d'un paquet selon nos besoins exacts. Vous vous familiariserez avec cette fonctionnalité au fur et à mesure que vous utiliserez Funtoo Linux. Le USE flag <code>binary</code> a été créé pour <code>debian-sources</code> ainsi que pour d'autres <code>ebuilds</code> de noyau afin que les nouveaux utilisateurs de Funtoo Linux  aient un système opérationnel le plus facilement possible.
+
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.
 
+
==== Mise en place du noyau ====
+
 
+
{{Note|Voir [[Funtoo Linux Kernels]] pour une liste complète des noyaux supportés par Funtoo Linux.  Nous recommandons <code>debian-sources</code> aux nouveaux utilisateurs.}}
+
 
+
{{Important|<code>debian-sources</code> compilé avec le USE flag <code>binary</code> requiert à tout le moins 14GB d'espace libre dans <code>/var/tmp</code> et prend environ 1 heure à être compilé et mis en place  quand la machine tourne sur un processeur Intel Core i7.}}
+
 
+
Installons le noyau:
+
 
+
<console>
+
(chroot) # ##i##emerge -1 @kernel
+
</console>
+
 
+
{{Important|Le paramètre <code>-1</code> fait en sorte que le paquet déclaré dans l'ensemble <code>kernel</code>, indiqué par <code>@kernel</code> sur la ligne de commande, ne se retrouvera pas dans l'ensemble <code>world</code>. Cela permet d'effectuer la mise à jour du noyau indépendamment des autres paquets constituant le système Funtoo Linux prévenant ainsi que le noyau soit mis à jour en même temps que le système.}}
+
 
+
La mise en place d'un noyau opérationnel et fonctionnel à l'aide du USE flag <code>binary</code> est à la fois simple et coûteux. C'est coûteux en terme de temps de compilation. Le noyau sera configuré pour soutenir toute la quincaillerie que Linux supporte. Cela prendra beaucoup de temps sur des machines lentes. C'est la raison pour laquelle il est important que la variable <code>MAKEOPTS</code> soit bien initialisée dans <code>/etc/portage/make.conf</code>. Voir la section [[#/etc/make.conf|/etc/make.conf]].
+
 
+
[[Category: Installation Guide Parts]]
+

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.