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

< Install‎ | fr(Difference between pages)
(Support canadien-français)
 
(two first cases for virtuals)
 
Line 1: Line 1:
<noinclude>
+
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.
{{InstallPart|configuration du système Funtoo Linux}}
+
</noinclude>
+
=== Configuration du système ===
+
  
Comme toutes les distributions Linux, Funtoo Linux possède son lot de fichiers de configuration. Un fichier qui ne doit en aucun cas échapper à votre attention est <code>/etc/fstab</code>. À défaut de le configurer correctement, Funtoo Linux refusera de démarrer.
+
== 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.
  
==== L'éditeur nano ====
+
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.
  
L'éditeur de texte disponible dans l'environnement «chroot» se nomme <code>nano</code>. Pour éditer l'un des fichiers ci-dessous, vous le lancez ainsi:
+
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.
  
<console>
+
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.
(chroot) # ##i##nano -w /etc/fstab
+
</console>
+
  
{{Note|L'argument '''w''' prévient le retour à la ligne automatique. On le recommande lors de l'édition de fichiers de configuration. Cela évite la possible insertion de caractères étrangers générant une erreur à l'exécution du contenu.}}
+
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.
+
Utilisez les touches fléchées pour vous déplacez dans l'éditeur. Les touches telles «backspace» et «delete» réagissent tel que prévu. Appuyez sur Ctrl+X pour sauvegarder le fichier en quittant l'éditeur.
+
  
==== Fichiers de configuration ====
+
== 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.
  
Voici une liste de fichiers de configuration à éditer pour modification selon vos besoins:
+
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 class="active"><th>Fichier</th>
+
=== System components and services ===
<th>Dois-je le modifier?</th>
+
Example: ''virtual/service-manager''
<th>Description</th>
+
</tr><tr  class="danger">
+
<td><code>/etc/fstab</code></td>
+
<td>'''Oui - requis'''</td>
+
<td>Instructions de montage de vos partitions lors du démarrage.</td>
+
</tr><tr>
+
<td><code>/etc/localtime</code></td>
+
<td>''Recommandé''</td>
+
<td>Votre fuseau horraire. Lien symbolique vers /usr/share/zoneinfo (i.e. /usr/share/zoneinfo/America/Toronto) </td>
+
</tr><tr>
+
<td><code>/etc/portage/make.conf</code></td>
+
<td>''Recommandé''</td>
+
<td>Paramètres utilisés par gcc (compilateur), portage, et make.</td>
+
</tr><tr>
+
<td><code>/etc/conf.d/hostname</code></td>
+
<td>''Recommandé''</td>
+
<td>Sert à affecter un nom à la machine.</td>
+
</tr><tr>
+
<td><code>/etc/conf.d/keymaps</code></td>
+
<td>Optionnel</td>
+
<td>Fichier de configuration pour le mappage du clavier. À modifier si votre clavier n'est pas US.</td>
+
</tr><tr>
+
<td><code>/etc/conf.d/hwclock</code></td>
+
<td>Optionnel</td>
+
<td>Fichier de configuration de l'horloge du système.</td>
+
</tr><tr>
+
<td><code>/etc/conf.d/modules</code></td>
+
<td>Optionnel</td>
+
<td>Modules du noyau à charger automatiquement au démarrage. Voir [[Additional Kernel Resources]] pour plus de détails.</td>
+
</tr><tr>
+
<td><code>/etc/conf.d/consolefont</code></td>
+
<td>Optionnel</td>
+
<td>Définition de la police d'affichage en console. Le service consolefont doit être actif. Démarrez-le ainsi: rc-update add consolefont.</td>
+
</tr><tr>
+
<td><code>profiles</code></td>
+
<td>Optionnel</td>
+
<td>Réglages pour Portage.</td>
+
</tr>
+
{{TableEnd}}
+
  
{{Warning|Éditez le fichier <code>etc/fstab</code> avant de redémarrer. Vous devez modifier le contenu des colonnes «fs» et «type» afin qu'il soit conforme aux partitions et aux systèmes de fichiers que vous avez créés avec <code>gdisk</code> ou <code>fdisk</code>. Vous pourriez être incapale de lancer Funtoo Linux en passant outre à cette étape.}}
+
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.
  
==== /etc/fstab ====
+
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.
  
La commande <code>mount</code> lit le fichier <code>/etc/fstab</code> lors du démarrage du système. Les énoncés de ce fichier fournissent à cette commande des informations à propos des partitions et lui indiquent comment les monter. Éditez le fichier afin que son contenu reflète exactement le partitionnement que vous avez créé plus tôt.
+
=== Tools provided by multiple packages ===
 +
Example: ''virtual/eject''
  
<console>
+
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).
(chroot) # ##i##nano -w /etc/fstab
+
</console>
+
  
<pre>
+
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.
# The root filesystem should have a pass number of either 0 or 1.
+
# All other filesystems should have a pass number of 0 or greater than 1.
+
#
+
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
+
#
+
# See the manpage fstab(5) for more information.
+
#
+
# <fs>     <mountpoint>  <type>  <opts>        <dump/pass>
+
 
+
/dev/sda1    /boot        ext2    noauto,noatime 1 2
+
/dev/sda2    none          swap    sw            0 0
+
/dev/sda3    /            ext4    noatime        0 1
+
/dev/sda4    /home        ext4    noatime        0 1
+
#/dev/cdrom  /mnt/cdrom    auto    noauto,ro      0 0
+
</pre>
+
 
+
{{Note|Ce fichier <code>/etc/fstab</code> montre qu'une partition <code>/home</code> a été créée afin de séparer les données du système, paritition racine, des données personnelles.}}
+
 
+
{{Note|Si vous utilisez <code>UEFI</code>, le système de fichiers pour la partition <code>/boot</code> doit être changé pour <code>vfat</code>. Il en va de même pour le système de fichiers <code>ext4</code> si vous avez formaté les partitions avec un autre système de fichiers, par exemple <code>XFS</code>.}}
+
 
+
==== /etc/localtime ====
+
 
+
<code>/etc/localtime</code> spécifie le fuseau horaire UTC par défaut. Si vous voulez que votre système utilise votre fuseau horaire, remplacez <code>/etc/localtime</code> par un lien symbolique vers le fuseau horaire souhaité.
+
 
+
<console>
+
(chroot) # ##i##ln -sf /usr/share/zoneinfo/Canada/Eastern /etc/localtime
+
</console>
+
 
+
Dans l'exemple ci-haut, le fuseau horaire est réglé sur l'heure normale de l'Est (Canada) supportant l'heure d'été. Exécutez la commande <code>ls /usr/share/zoneinfo</code> pour voir les différents fuseaux horaires disponibles.
+
 
+
==== /etc/make.conf ====
+
 
+
MAKEOPTS  détermine le nombre de compilations en parallèle qui devraient se produire lorsque vous compilez un paquet. Cela peut  grandement améliorer le temps de compilation.  La règle d'or dicte d'ajouter 1 au nombre de processeurs. À titre d'exemple, si vous avez un processeur double coeur sans [[http://fr.wikipedia.org/wiki/Hyper-Threading|hyper-threading]], vous initialiserez MAKEOPTS avec 3:
+
 
+
<pre>
+
MAKEOPTS="-j3"
+
</pre>
+
 
+
<code>nproc</code> vous aide à obtenir le nombre de processeurs.
+
<console>
+
(chroot) # ##i##nproc
+
4
+
</console>
+
 
+
<pre>
+
MAKEOPTS="-j5"
+
</pre>
+
 
+
Les USE flags servent à préciser les fonctionnalités d'un paquet quand il est compilé. N'en ajoutez pas trop lors de l'installation. Attendez plutôt d'avoir un système fonctionnel avant de les modifier. Un signe moins ("<code>-</code>") devant un USE flag informe Portage de l'ignorer quand il compile le système ou un paquet. Vous trouverez de la documentation sur les USE flags dans le [http://www.gentoo.org/doc/fr/handbook/handbook-amd64.xml?part=2&chap=2 manuel de Gentoo] en attendant qu'un guide Funtoo sur les USE flags soit disponible.
+
 
+
LINGUAS indique à  Portage dans quelle langue compiler le système et les applications qui utilisent LINGUAS, par exemple LibreOffice). Pour le support en Français:
+
 
+
<pre>
+
LINGUAS="fr"
+
</pre>
+
 
+
==== /etc/conf.d/hwclock ====
+
 
+
Si vous installez Funtoo Linux en parallèle avec Windows, vous devez changer la valeur de '''clock''' en remplaçant '''UTC''' par '''local'''. Windows règle l'horloge matérielle à l'heure locale chaque fois que vous lancez Windows.
+
 
+
<console>
+
(chroot) # ##i##nano -w /etc/conf.d/hwclock
+
</console>
+
 
+
==== Autres francisations ====
+
 
+
Le système Funtoo Linux est livré en Anglais américain. Il supporte la norme de codage [http://fr.wikipedia.org/wiki/UTF-8 UTF-8]. Nous devons modifier quelques fichiers afin d'avoir un système qui soit entièrement en Français. Nous avons déjà modifié le fichier <code>/etc/portage/make.conf</code> afin que le système soit compilé en Français. Nous avons toutefois d'autres fichiers à modifier, par exemple pour un clavier français ou canadien-français.
+
 
+
==== Réglages linguistiques ====
+
 
+
Il y a deux fichiers de configurations responsable des réglages linguistiques dans Funtoo Linux. L'un est <code>/etc/locale.gen</code> alors que l'autre est <code>/etc/env.d/00basic</code>.  Le premier définit la langue comme étant l'Anglais américain. Le second, un fichier par défaut, livré avec le Stage3 , sert à définir la langue à l'échelle du système.  Nous ne recommandons pas de l'éditer.
+
 
+
==== Support canadien-français ====
+
 
+
Éditons le fichier <code>/etc/locale.gen</code> dans un premier temps:
+
 
+
<console>
+
# ##i##nano -w /etc/locale.gen
+
</console>
+
 
+
Spécifiez votre préférence accompagnée du format UTF-8:
+
 
+
{{file|name=/etc/locale.gen|body=
+
en_US.UTF-8 UTF-8
+
fr_CA.UTF-8 UTF-8
+
}}
+
 
+
{{Warning|Il est fortement recommandé de conserver le réglage par défaut comme alternative.}}
+
 
+
Générons le tout maintenant:
+
 
+
<console>
+
# ##i##locale-gen
+
##g##*##!g## Generating 2 locales (this might take a while) with 1 jobs
+
*  (1/2) Generating en_US.UTF-8 ... [ ok ]
+
*  (2/2) Generating fr_CA.UTF-8 ... [ ok ]
+
##g##*##!g## Generation complete
+
</console>
+
 
+
Appliquons les réglages à l'ensemble du système. Affichons les options disponibles:
+
 
+
<console>
+
# ##i##eselect locale list
+
##b####g##Available targets for the LANG variable:
+
  ##b##[1]##!b##  C
+
  ##b##[2]##!b##  POSIX
+
  ##b##[3]##!b##  en_US.utf8 ##bl##*
+
  ##b##[4]##!b##  fr_CA.utf8
+
  ##b##[ ]##!b##  (free form)
+
</console>
+
 
+
L'étoile bleue indique le réglage actuel. Changeons-le pour Canada-Français:
+
 
+
<console>
+
# ##i##eselect locale set 4
+
Setting LANG to fr_CA.utf8 ...
+
Run ". /etc/profile" to update the variable in your shell.
+
</console>
+
 
+
Finalement, nous appliquons les réglages à l'ensemble du système:
+
 
+
<console>
+
# ##i##env-update && source /etc/profile
+
>>> Regenerating /etc/ld.so.cache...
+
</console>
+
 
+
Vérifications des nouveaux réglages:
+
 
+
<console>
+
# ##i##eselect locale show
+
##b####g##LANG variable in profile:
+
  ##b##fr_CA.utf8
+
</console>
+
 
+
==== Clavier (/etc/conf.d/keymaps)====
+
 
+
Éditez le fichier <code>/etc/conf.d/keymaps</code> et changez la valeur de '''keymap''' pour '''cf''' si c'est un clavier QWERTY canadien-français ou pour '''fr''' s'il s'agit d'un clavier AZERTY français.
+
 
+
<console>
+
# ##i##nano -w /etc/conf.d/keymaps
+
</console>
+

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.