Gentoo Francophone

elogv

Stephane Malinet — 2008-03-16T09:53:05Z

elogv est un utilistaire en ligne de commande permettant de lire et de gérer les méssages générés par portage lors de l'installation d'un paquet.

Pour installer app-portage/elogv, il suffit de taper la commande qui suit :

# emerge -av app-portage/elogv

Pour la configuration, éditez le fichier /etc/make.conf et ajoutez-y les lignes suivantes :

PORTAGE_ELOG_SYSTEM="save"
 PORTAGE_ELOG_CLASSES="warn error info log qa"

Vous pouvez bien sûr enlevez certaines options, pour leurs détails reportez-vous au fichier /etc/make.conf.example.

Lancez, par exemple, la compilation du paquet mail-mta/postfix, une fois terminée, lancez elogv, vous obtiendrez les méssages d'informations, de warnings et d'érreurs s'il y en a.

Tapez F1 pour afficher l'aide, et ainsi voir toutes les commandes disponibles...

En conclusion cet utilitaire s'avère trés pratique après de grosses mise à jour afin de pouvoir lire les méssages des ebuilds.

Les Overlays de Gentoo

max — 2007-01-21T11:36:26Z

[titre1]Introduction[/titre1]

L'équipe de Gentoo est ravi d'annoncer l'ouverture d'un nouveau service destiné à centraliser les overlays de développement « Gentoo Overlays ». Stuart Herbert, le fondateur du projet, voit ce service, overlays.gentoo.org, comme un moyen de créer un espace où les développeurs et utilisateurs, pourront travailler main dans la main pour améliorer la distribution Gentoo.

Les « Overlays » sont des arbres de paquets externes à l'arbre officiel de portage. Ils sont maintenus et distribués séparement de l'arbre principal. Ils permettent à quiconque de distribuer ses ebuilds pour la distribution Gentoo.

Les environnements de travail, hébergés sur le site overlays.gentoo.org, offrent un espace de test et de developpement pour les équipes de gentoo qui travaillent avec les utilisateurs. Ensemble, les utilisateurs et les développeurs pourront donc travailler sur les nouveaux paquets et améliorer les paquets existants de Gentoo.

[titre2]Pourquoi créer des Overlays ?[/titre2]

Si tu modifies un ebuild dans /usr/portage, tes changements seront perdus aprés une synchronisation de l'arbre avec emerge —sync. En revanche, si tu le mets dans un overlay, la synchronisation ne touchera pas à ton ebuild.
Les overlays permettent d'avoir des arbres de développement et de test sans « casser » l'arbre officiel.
Ils sont facile à diffuser.

[titre1]Installation d'un overlay de Gentoo[/titre1]

[titre2]Qu'est-ce que layman ?[/titre2]

Layman est un outil pour gérer les overlays du système Gentoo. On lui donne des adresses correspondant aux fichiers contenant les listes des overlays. Et ensuite, il suffit de lui dire quel overlay télécharger.

[titre2]Installation[/titre2]

L'outil layman posséde un ebuild dans l'arbre officiel, il suffit de passer par emerge pour l'installer :

$ emerge -av layman

Ensuite, vous indiquerez la référence du fichier /usr/portage/local/layman/make.conf qui contient la liste des overlays dans /etc/make.conf :

$ echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf

[titre2]Configuration[/titre2]

Le fichier de configuration de layman est /etc/layman/layman.cfg. Rien de plus simple pour le configurer, il suffit de l'éditer pour ensuite modifier les variables :

config_dir : Le chemin du répertoire de configuration de layman. Elle sera surement supprimer dans les versions prochaines.
storage : Le chemin du répertoire contenant les overlays. Par défaut, c'est /usr/portage/local/layman pour une bonne raison : l'arbre officiel peut être sur un serveur nfs ou smb pour n'avoir qu'un arbre pour plusieurs machines. Donc l'overlay ne sera synchronisé qu'une fois pour toutes les machines locales.
cache : layman va stocker la liste des overlays ici dans chaque fichier cache_*. Vous indiquerez juste le début du chemin. La fin sera complétée par layman par le md5 de l'url.
local_list : le chemin du fichier qui contiendra la liste des overlays installés sur votre système.
make_conf : le chemin du make.conf local qui sera modifié par layman à chaque ajout d'overlay. Il contiendra la variable PORTDIR_OVERLAY qui liste les overlays installés. Attention, il ne faut pas oublier d'en faire référence dans le fichier /etc/make.conf.
overlays : la liste des urls contenant la liste des overlays. Par défaut, il n'y a que http://www.gentoo.org/proj/en/overlays/layman-global.txt.
proxy : si tu as un proxy, il suffit d'indiquer son adresse. Même si layman supporte le proxy, il ne supporte pas encore l'authentification au proxy.
nocheck : il faut indiquer si oui (1) ou non (0), layman doit vérifier s'il manque l'url ou la description d'un overlay.

[titre2]Utilisation de layman[/titre2]

Voici les quelques actions de layman :

Télécharger ou mettre à jour la liste des overlays : $ layman -f
Afficher la liste des overlays disponibles : $ layman -L
Selectionner et installer un overlay : $ layman -a nom_overlay
Supprimer un overlay du système : $ layman -d nom_overlay
Synchroniser un overlay : $ layman -s nom_overlay
Synchroniser tous les overlays : $ layman -S

[titre2]Pour plus d'informations[/titre2]

Dispatch-conf

TGL — 2006-04-19T12:07:49Z

Dispatch-conf est un utlistaire de portage afin de mettre à jour ses fichiers de configurations lorsque ces derniers doivent être modifiés suite à une mise à jour.

Au delà des aspects cosmétiques de l'interface (que je trouve plus agréable aussi), il y a quand même quelques différences plus fondamentales entre dispatch-conf et etc-update.

Tout d'abord, dispatch-conf effectue des sauvegardes à chaque intervention, soit sous forme de copies fichier.version dans un répertoire donné, soit sous forme RCS (un gestionnaire de version monoutilisateur, un genre de mini-CVS quoi). Ces sauvegardes permettent de retrouver les fichiers écrasés un peu trop vite, ou encore les fichiers tels qu'ils avaient été installés par le paquet si on a fait n'importe quoi dedans.

Mais surtout, dispatch-conf repose pour les mises à jour sur un diff à 3 fichiers entre : (1) - l'ancien fichier vanilla (le /etc/toto.conf tel qu'installé par le paquet toto-1.0) (2) - le nouveau fichier vanilla (le /etc/._cfg0001_toto.conf qu'y vient d'être installé par votre mise à jour vers toto-1.1) (3) - votre fichier customisé, dérivé de (1) (votre /etc/toto.conf actuellement en usage)

Ce que dispatch-conf propose donc, ça n'est pas simplement comme etc-update de remplacer (3) par (2) en oubliant tout au passage, mais plutôt d'intégrer à (3) les différences entre (1) et (2) :
s'il n'y a pas de différence (toto-1.0 et toto-1.1 propose la même config par défaut), il n'y a donc rien à faire, et dispatch-conf ne vous parlera même pas de ce fichier, quand bien même vous l'auriez configuré.
si les différences ne concernent que des lignes de commentaires, alors dispatch-conf en fera aussi silencieusement l'intégration (pour peu qu'il soit configuré pour, voir plus bas).
sinon, il vous proposera un merge interactif ou ce genre de choses, comme etc-update. Mais attention, il y aura moins de lignes à merger, puisque vos customisations portant sur des lignes communes à la conf 1.0 et 1.1 seront elles déjà automatiquement intégrées.

Bon, ça sera plus clair sur un exemple...

Commençons par configurer dispatch-conf, dans /etc/dispatch-conf.conf :

#
 # dispatch-conf.conf
 #
 
 # Directory to archive replaced configs
 archive-dir=/var/archive/config
 
 # Use rcs for storing files in the archive directory?
 # (yes or no)
 use-rcs=no
 
 # Diff for display
 diff="colordiff -Nu %s %s"
 
 # Pager for diff display
 pager="less --no-init --QUIT-AT-EOF -R"
 
 # Automerge files comprising only CVS interpolations (e.g. Header or Id)
 # (yes or no)
 replace-cvs=yes
 
 # Automerge files comprising only whitespace and/or comments
 # (yes or no)
 replace-wscomments=yes
 
 # Automerge files that the user hasn't modified
 # (yes or no)
 replace-unmodified=yes
 
 # Per-session log file of changes made to configuration files
 log-file=/var/log/dispatch-conf.log

Ici, j'ai choisi une sauvegarde sous forme de fichiers dans le répertoire /var/archive/config, et j'ai activé toutes les options qui facilitent la vie. Oh, et puis oui, j'ai remplacé diff par colordiff, parce que c'est plus joli ; si vous le faites aussi, pensez à installer ce programme :

# emerge -av colordiff

Maintenant, il faut savoir que dispatch-conf peut travailler sur un répertoire bidon qu'on lui passe en paramètre, au lieu des habituels /etc/ et compagnie. C'est ce qu'on va utiliser pour le test, comme ça on fait pas de bêtises. Mais dans la vraie vie, au lieu de dispatch-conf /foo/bar/, on ferait juste dispatch-conf.

% mkdir /tmp/etc
 % <éditeur> /tmp/etc/toto.conf

On va commencer avec un toto.conf comme si on venait d'installer un paquet toto-1.0 :

# This is configuration file for toto
 # This option roxor:
 roxor=yes
 # This option puxor:
 puxor=no

Comme c'est une première installation, il n'y a pas dispatch-conf ou autre etc-update à faire. Imaginons maintenant qu'on met à jour vers toto-1.1. Ça installe un fichier de config légèrement différent :

% cp /tmp/etc/toto.conf /tmp/etc/._cfg0001_toto.conf
 % <éditeur> /tmp/etc/._cfg0001_toto.conf

Disons que la nouvelle version aura quelques commentaires en plus à la fin :

# This is configuration file for toto
 # This option roxor:
 roxor=yes
 # This option puxor:
 puxor=no
 # Optionally, you can set TGL's verbosity here:
 #tglverb=3

Il est tant de faire un premier merge avec cette nouvelle configuration :

% dispatch-conf /tmp/etc/

Ici, on n'a pas eu à intervenir, parcequ'il ne s'agit que de merger des commentaires. Mais pourtant, le boulot est bel et bien fait, les lignes ayant été ajoutées :

% <éditeur> /tmp/etc/toto.conf

Et on voit :

# This is configuration file for toto
 # This option roxor:
 roxor=yes
 # This option puxor:
 puxor=no
 # Optionally, you can set TGL's verbosity here:
 #tglverb=3

Bon bah on va en profiter pour augmenter un peu la valeur de "tglverb", avant d'enregistrer :

...
 # Optionally, you can set TGL's verbosity here:
 tglverb=9

Bon, maintenant, et c'est là qu'on découvre la vraie puissance de dispatch-conf, on va faire une mise à jour vers un toto-1.2, dont la conf par défaut (roxor=yes et puxor=no) a été inversée. On se refait donc encore un "._cfg0001_toto.conf" qui ressemble cette fois à ça :

# This is configuration file for toto
 # This option roxor:
 roxor=no
 # This option puxor:
 puxor=yes
 # Optionally, you can set TGL's verbosity here:
 #tglverb=3

Et on le fusionne :

% dispatch-conf /tmp/etc/
 --- /tmp/etc/toto.conf 2005-09-03 02:10:51.000000000 +0200
 +++ /tmp/etc/._mrg0001_toto.conf 2005-09-03 02:11:34.000000000 +0200
 @@ -1,10 +1,10 @@
 # This is configuration file for toto
 # This option roxor:
 -roxor=yes
 +roxor=no
 # This option puxor:
 -puxor=no
 +puxor=yes
 # Optionaly, you can set TGL's verbosity here:
 tglverb=9
 
 >> (1 of 1) -- /tmp/etc/toto.conf
 >> q quit, h help, n next, e edit-new, z zap-new, u use-new
 m merge, t toggle-merge, l look-merge:

On voit dispatch-conf afficher les modifications qu'il propose (changer les valeurs de "roxor" et "puxor", puisqu'elle sont changées dans la conf par défaut). Mais ce qu'il convient surtout de remarquer, c'est que notre customisation de "tglverb", elle, est conservée. Ici, etc-update aurait proposé de revenir à un ligne "#tglverb=3" telle qu'elle est dans la conf par défaut. Ça ne vous impressionne pas ? Et bah dites vous que si les lignes customizées c'était vos entrées de /etc/fstab, vous apprécieriez qu'on ne vous propose même pas de les massacrer. Bon, après cet intermède, il est temps d'accepter les modifs proposées. On appuie donc sur "u" (use-new), et dispatch-conf quitte en enregistrant la nouvelle version. Je vous laisse regarder "man dispatch-conf" pour les autres commandes. On a donc maintenant :

% cat /tmp/etc/toto.conf
 # This is configuration file for toto
 # This option roxor:
 roxor=no
 # This option puxor:
 puxor=yes
 # Optionaly, you can set TGL's verbosity here:
 tglverb=9

Et on peut aussi jetter un oeil aux sauvegardes, où l'on retrouve nos précédentes versions de toto.conf, et la version d'origine (celle en ".dist") :

% ls /var/archive/config/etc/tmp
 toto.conf toto.conf.1 toto.conf.dist

Et voilà pour la démo... en éspèrant qu'elle rend la chose un peu plus compréhensible. Mais si vous avez rien capté, retenez quand même au moins ça :
dispatch-conf fait des sauvegardes, et c'est Bien© ;
dispatch-conf est plus malin qu'etc-update, vous laissant moins de travail à faire manuellement, et donc moins de chances de faire des fausses manips.

Ah oui, pour finir, un bémol tout de même : la première fois qu'il voit un fichier, dispatch-conf n'a pas encore dans ces archive de sauvegarde de la précédente version du fichier standard, et ne peut donc pas faire grand chose d'intelligent (sinon les petits trucs comme la fusion de commentaires)... Ça n'est donc que à partir de la 2ème mise-à-jour d'un fichier qu'il devient intérressant. Bref, il faut l'utiliser régulièrement depuis quelques temps pour bien le juger.

Cet article est tiré du TIP etc-update des forums officiels Gentoo

Fonctionnement de Portage

max — 2005-12-09T19:55:42Z

[titre1]L'arbre PORTAGE[/titre1]

[titre2]Quelques explications[/titre2]

Quand vous exécutez la commande emerge —sync, vous télécharger le dernier arbre officiel sur les serveurs rsync de Gentoo. Il se situe le plus souvent dans /usr/portage, cela dépend aussi de la configuration du make.conf. L'arbre possède une cinquantaine de sections qui évoluent chaque jour. Dans ses sections, il y a pour chaque paquet un répertoire où se situe :

un ebuild pour chaque version : liste de commandes Portage pour installer un paquet
un Changelog : indique les améliorations de chaque version
un metadata : fichier xml qui donne plus de précision sur le paquet
un Manifest : fichier signé en PGP qui donne le MD5 de chaque fichier, le nom du fichier exact, et sa taille. Il sert à vérifier l'intégrité des sources téléchargées
un répertoire files : fichier digest-nomdupaquet-version qui indique le MD5, le nom du fichier exact et la version (comme dans le Manifest)

Si nous revenons dans /usr/portage, nous aperçevons des répertoires autres que des catégories de paquets :

distfiles : il comprend tous les fichiers téléchargés pendant l'installation d'un paquet
eclass : dans ce répertoire, on trouve tous les scripts eclass qui sont des fonctions appelées dans les ebuilds
metadata : ce répertoire possède le cache des ebuild, glsa (Gentoo Linux Security Advisory) qui contient toutes les annonces de vulnérabilités des paquets et d'autres fichiers comme timestamp...
packages : on y trouve toutes les archives des binaires des paquets
profiles : dans ce répertoire, on trouve tous les profiles de Gentoo

On en conclut que l'arbre portage comprend les ebuilds avec une organisation bien spéciale : catégorie/paquet/paquet-version.ebuild et a aussi des fichiers spéciaux pour Portage. Il peut être modifié à tout moment grâce à la commande emerge —sync. Vous pouvez aussi avant de faire cette manipulation, voir les nouveaux paquets de l'arbre portage ici.

[titre2]Représentation graphique[/titre2]


Représentation de l'arbre portage

[titre1]Fonctionnement d'emerge[/titre1]

Dans cette section, nous décrivons en gros le fonctionnement d'emerge pour l'installation, la désinstallation... toutes les actions importantes et régulières que vous faites avec emerge.

[titre2]emerge categorie/paquet[/titre2]

Emerge regarde dans le fichier /etc/make.conf pour prendre en compte toutes les options,
regarde si le paquet existe dans /usr/portage,
regarde dans d'autres fichiers comme /etc/portage/package.unmask, /etc/portage/use...,
créé à la fin de l'installation un répertoire avec plein d'informations concernant le paquet dans /var/db/pkg/section/,
et installe le paquet.

[titre2]emerge -C categorie/paquet ou emerge unmerge categorie/paquet[/titre2]

Emerge fait le même fonctionnement que l'installation d'un paquet,
regarde si le paquet est installé,
supprime le répertoire du paquet qui se situe dans /var/db/pkg/section,
désinstalle le paquet.

[titre2]emerge —sync[/titre2]

Emerge regarde dans le fichier /etc/make.conf,
indique à la fin s'il est important de faire une mise à jour et s'il a téléchargé un nouvel ebuild de portage,
indique dans un fichier dans /usr/portage/profiles/updates, les transitions des noms de paquets,
télécharge l'arbre portage et
supprime tous les fichiers dans /usr/portage/ qui ne sont pas dans l'arbre actuel.

[titre2]emerge -u world[/titre2]

Emerge regarde dans le fichier /etc/make.conf,
regarde dans le fichier /var/lib/portage/world qui indique les paquets qui ont des changements dans leur répertoire (exemple : /usr/portage/app-portage/abeni),
regarde dans le répertoire /etc/make.profile pour respecter ce qu'indique le profile utilisé (la version de Gentoo),
et met à jour.

[titre2]emerge —clean[/titre2]

Nettoie le système en enlevant les paquets qui ne sont plus à jour et qui ne vont pas supprimer de fonctionnalités et, de ce fait, préserve le bon fonctionnement de votre système.

[titre2]emerge —depclean[/titre2]

Nettoie le système en enlevant les paquets qui ne sont pas associés avec des paquets fusionnés explicitement. Depclean fonctionne en créant l'arbre de dépendance complet pour la liste du système et le fichier world, et en le comparant aux paquets installés. Les paquets installés, mais non associés avec une fusion explicite sont listés comme des candidats pour une désinstallation.

[warn]Ceci peut gravement affecter votre système en supprimant des paquets qui pourrait avoir été liés à d'autres, mais qui en raison d'un changement dans les drapeaux USE peuvent ne plus faire partie de l'arbre profond.[/warn]

[titre2]emerge —metadata[/titre2]

Force portage à gérer tous les fichiers du métacache qui sont normalement gérés à la fin d'une queue d'une mise à jour rsync utilisant "emerge —sync". Le traitement cré la base de donnée du cache que portage utilise pour consulter les données des paquets.

[titre2]emerge —regen[/titre2]

Provoque la vérification et la mise à jour par portage du cache des dépendances de tous les ebuilds dans l'arbre portage. Ce n'est pas recommandé pour des utilisateurs de rsync puisque rsync met à jour le cache en utilisant les caches des autres serveurs. Les utilisateurs devraient simplement faire 'emerge —sync' pour regénérer.

[titre2]Autres options[/titre2]

—ask : elle propose les USES d'un paquet, ensuite elle affiche les dépendances de ce paquet et elle vous demande si vous voulez installez ce paquet avec les dépendances.

—buildpkg : elle sert à créer les binaires d'un paquet avec le fusionnement véritable du paquet.

—buildpkgonly : c'est exactement l'option précédente sauf qu'il n'y a aucun fusionnement véritable.

—changelog : cette option ne peut marcher qu'avec —pretend. Elle affiche toutes les dépendances d'un paquet et s'il est installé ou non et il affiche les changements de chaque version du paquet designé.

—debug : elle sert à installer avec le mode debug, c'est-à-dire qu'elle va faire des commentaires ou indiquer des erreurs.

—deep : elle est utilisée avec l'option —update. Elle force la mise à jour des dépendances d'un paquet non-cité dans l'ebuild.

—emptytree : cette option peut-être très utile si l'utilisateur a du temps libre :). Par exemple quand vous mettez un nouvel USE (ou une nouvelle USE, je sais pas comment dire), et que vous voulez que toutes les paquets installés utilisent ce USE, il faut donc recompiler tous les paquets. Cette option refusionne tous les paquets installés sur votre système.

—fetchonly : elle télécharge juste le paquet indiqué et ses dépendances mais elle ne compile rien. Avec l'option —pretend, emerge vous montrera les URLS avec tous les mirroirs.

—fetch-all-uri : même fonctionnement que l'option précédente sauf que tous les fichiers des paquets, y compris ceux non exigés, seront téléchargés.

—getbinpkg : elle indique à Portage de télécharger le paquet binaire depuis le serveur que vous avez défini dans la variable PORTAGE_BINHOST. Elle est utilisée avec l'option "—usepkg".

—getbinpkgonly : Elle est indentique par rapport à celle précédente, sauf qu'elle n'utilise aucune information de la machine locale. Tous les paquets seront téléchargés sur un serveur sans consulter l'annuaire des paquets.

—newuse : Avec cette option, vous pouvez à présent reconstruire tous les paquets qui n'ont pas eu les nouveaux drapeaux de votre variable USE. Un astérisque est marqué quand un drapeau a été changé depuis la première installation du paquet.

—noconfmem : Portage maintient les fichiers qui ont été placés dans les répertoires CONFIG_PROTECT, et normalement il ne fusionnera pas le même fichier plus d'une fois. Ceci peut aboutir à des problèmes quand l'utilisateur veut le fichier dans le cas d'une suppression accidentelle. Avec cette option, les fichiers seront toujours fusionnés dans le fs réel au lieu d'être perdus.

—nodeps : Comme son nom l'indique, emerge n'installe que le paquet indiqué, les dépendances sont ignorées. L'option est fortement déconseillée.

—noreplace : si un paquet est déjà installé, emerge passe alors au paquet suivant.

—oneshot : Emerge installe le paquet normalement sauf qu'il ne l'inscrit pas dans le fichier world. Il ne sera mis à jour que s'il dépend d'un paquet que vous voulez installer.

—onlydeps : cela n'emerge que les dépendances du paquet indiqué, sans le fusionnement du paquet.

—pretend : cette option affiche soit les dépendances et le paquet indiqué, soit tous les paquets qui seront mis à jour, tout en indiquant si le(s) paquet(s) est installé(s) ou pas, sa(ses) version... Le N correspond à Nouveau, le U à la mise à jour(update), le R à remplacement, le F à recherche restreinte(find) et le B à bloqué.

—resume : quand vous arrêtez volontairement la compilation, avec cette option, emerge reprend au paquet arrêté.

—searchdesc : vous pouvez chercher une description d'un paquet en indiquant quelques mots avec cette option.

—skipfirst : Cette option est seulement valide dans un contexte de synthèse. Elle supprime le premier paquet dans la liste du résumé et ainsi une fusion peut se poursuivre malgré la présence d'une erreur fausse ou sans importance. Ceci doit seulement être utilisé dans les cas où passer le paquet ne provoque pas d'échec de dépendances.

—tree : Montre l'arbre de dépendance en utilisant l'indentation pour les dépendances.

—usepkg : Demande à emerge d'utiliser des paquets binaires (depuis $PKGDIR)) s'ils sont disponibles, et, de ce fait, évite probablement un temps certain de compilation. Cette option est utile pour les installations CD ; vous pouvez exporter PKGDIR=/mnt/cdrom/packages et alors utiliser cette option pour avoir emerge qui "attire" les paquets binaires depuis le CD afin de satisfaire les dépendances.

—usepkgonly : Comme —usepkg ci-dessus, excepté que cela permet uniquement d'utiliser des paquets binaires, et que la fusion sera abandonnée si le paquet n'est pas disponible au moment du calcul des dépendances.

—verbose : Les effets varient mais le résulat général est une sortie augmentée ou étendue du contenu des affichages de portage.

[titre1]Fonctionnement d'un ebuild[/titre1]

L'ebuild, comme on l'a vu précédemment, est un script où est indiqué une liste de commandes Portage pour installer le paquet que l'on souhaite. Pour plus d'informations sur les commandes Portage de l'ebuild, allez sur le guide du développeur de Gentoo.

[titre2]En-tête de l'ebuild[/titre2]

# Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/app-misc/worker/worker-2.8.4.ebuild,v 1.6 2004/10/05 13:34:52 pvdabeel Exp $

Note : La syntaxe de l'en-tête doit être exactement identique à celle du fichier /usr/portage/header.txt

[titre2]Description du paquet[/titre2]

DESCRIPTION="Worker Filemanager: Amiga Directory Opus 4 clone"

[titre2]Le site officiel du paquet[/titre2]

HOMEPAGE="http://www.boomerangsworld.de/worker/"

[titre2]L'adresse de l'archive du paquet[/titre2]

SRC_URI="http://www.boomerangsworld.de/worker/downloads/${P}.tar.bz2"

Note : Si jamais la variable SRC_URI n'est pas précisée, alors emerge va prendre l'adresse définie dans la variable GENTOO_MIRRORS du fichier /etc/make.conf.

[titre2]La licence du paquet[/titre2]

LICENSE="GPL-2"

[titre2]Indique qu'il n'y aura qu'une version installée de ce paquet[/titre2]

SLOT="0"

[titre2]Les architectures supportées par le paquet[/titre2]

KEYWORDS="x86 ppc ~amd64 ~ia64 ~sparc alpha ~hppa ~mips"

[titre2]Les paquets dépendants[/titre2]

DEPEND="virtual/x11"

[titre2]Section pour l'installation[/titre2]

src_install() {

[titre2]Installation[/titre2]

make DESTDIR=${D} install || die "install problem"

[titre2]Commande qui installe les fichiers man[/titre2]

doman man/worker.1

[titre2]Commande qui installe la documentation[/titre2]

dodoc AUTHORS ChangeLog INSTALL NEWS README README_LARGEFILES THANKS

[titre2]Fermeture de la section[/titre2]

}

[titre1]Utilisation avancée d'emerge[/titre1]

[titre2]Démasquer un paquet[/titre2]

Dans l'arbre portage, on peut trouver des paquets masqués, c'est-à-dire qu'ils sont très instables. On ne peut donc pas les emerger directement avec emerge. Il faut déjà passer par une manipulation pour les démasquer et ensuite les installer.

$ mkdir /etc/portage
 $ echo x11-libs/evas >> /etc/portage/package.unmask

[warn]La syntaxe à respecter est : catégorie/paquet. Vous pouvez aussi préciser la version (=categorie/paquet-version). D'autre part, il ne faut surtout pas faire ceci (cela pourrait provoquer une défaillance par la suite) :[/warn]

$ emerge /usr/portage/x11-libs/evas/evas-9999.ebuild

[titre2]Masquer un paquet[/titre2]

Si vous voulez par exemple qu'emerge ne fasse pas une mise à jour d'un certain paquet, vous pouvez le masquer et comme ca emerge ne posera plus de problème. La syntaxe est la même que pour démasquer un paquet : categorie/paquet. Vous pouvez aussi préciser la version à l'aide de = (=categorie/paquet-version). Par contre, au lieu d'utiliser le fichier /etc/portage/package.unmask, vous utiliserez /etc/portage/package.mask.

[titre2]Attribuer des USE pour chaque paquets[titre2]

Si vous voulez attribuer des USE pour un cas précis de paquet, il est préférable d'utiliser le fichier /etc/portage/package.use que de faire :

$ USE="foo" emerge bar

La syntaxe du fichier est la même que les fichiers /etc/portage/package.* :

(exemple)
 media-video/mplayer -arts dvd nvidia fbcon xvid libcaca matroska real divx4linux dvdread mmx mmxext 3dnow 3dnowext sse win32codecs -xmms custom-cflags -gtk
 =sys-libs/slang-1.4.9-r2 unicode

[titre2]Changer l'architecture d'un paquet[/titre2]

Il existe pour le changement d'architecture d'un paquet comme pour le démasquage un fichier /etc/portage/package.keywords. La syntaxe a respecter se présente comme ceci : catégorie/paquet architecture.

$ mkdir /etc/portage
 $ echo x11-misc/lookingglass-bin x86 >> /etc/portage/package.keywords

Note : Pareil que pour le masquage et démasquage d'un paquet, vous pouvez préciser la version du paquet.

[titre2]Reconstruction d'un paquet avec de nouveaux drapeaux USE[/titre2]

Vous pouvez à présent reconstruire tous les paquets qui n'ont pas eu les nouveaux drapeaux de votre variable USE. Un astérisque est marqué quand un drapeau a été changé depuis la première installation du paquet.

L'option a utiliser est : —newuse

$ emerge --newuse --ask world

[titre2]Manipulation améliorée de l'injection[/titre2]

L'injection qui se fait par l'option —inject + paquet sert à dire que telle version de paquet est installée même si elle ne l'est pas ou n'existe pas.

Pour l'instant, l'injection est encore instable. Cette méthode devra se faire non pas par l'option —inject mais en indiquant la catégorie du paquet et sa version (syntaxe : categorie/paquet-version) dans le fichier /etc/portage/profiles/package.provided .

$ emerge --inject x11-base/evoak-0.0.1.20040807

[titre2]GPG dans Portage[/titre2]

Chaque paquet possède un Manifest dans son répertoire, contenu dans l'arbre portage. Le Manifest possède la taille et le MD5 de l'archive du paquet, du Changelog, de l'ebuild... Ce fichier sert à Portage qui va vérifier que l'archive du paquet n'a pas été corrompue. Dans tous les nouveaux Manifest, le Manifest est signé par une clé PGP.

Pour une sécurité suplémentaire, une fonction a été intégrée : gpg qui sert à vérifier que la signature n'a pas été elle aussi corrompue. Plusieurs stades de sécurité existent : strict ou severe strict. Cette fonction n'est pas encore très stable. Si vous n'arrivez pas à la faire marcher, c'est normal.

stade minimum de vérification

FEATURES="gpg"

stade moyen

FEATURES="gpg strict"

stade paranoïaque

FEATURES="gpg severe strict"

[titre2]Quelques fonctionnalités de Portage[/titre2]

La dernière version de portage, 2.0.51, intégre des nouvelles fonctionnalités. Petit rappel : pour utiliser les fonctions, il faut les entrer dans la variable FEATURES du fichier /etc/make.conf.

maketest : Cette fonction effectue un test du paquet à la fin de la compilation. Tous les paquets ne possèdent pas un test de vérification.

autoconfig : Cette fonction sert à faire la mise à jour des scripts config.sub et config.guess (qui servent en partie à la configuration de la compilation d'un paquet) contenu dans un paquet par l'outil gnuconfig (config.sub et config.guess) et contenu dans votre système (/usr/share/gnuconfig/). Ceci sert à ce que la configuration soit la même pour chaque paquet.

gpg : Elle sert à vérifier les signatures gpgp des Manifests et s'assurent qu'elles sont correctes.

Eix : Ebuild IndeX (outil de recherche d'ebuild)

max — 2005-12-08T19:11:18Z

[titre1]Introduction à Eix[/titre1]

Eix est un petit utilitaire écrit en C++ qui devrait remplacer esearch pour une raison toute simple : il est beaucoup plus rapide. Vous l'aurez compris, la principale fonction d'eix est l'indexation des ebuilds de portage et des arbres non-officiels, ce qui permet de faire des recherches plus rapidement qu'avec emerge -s...

Donc plusieurs raisons pour utiliser eix :

Indexation et recherche des ebuilds rapides.
Configuration impressionante du rendement des informations.
Fournit plus d'informations que la commande esearch ou emerge -s, c'est-à-dire qu'il montre chaque version disponible.

[titre2]Installation[/titre2]

Si vous n'êtes pas en testing, c'est à dire ACCEPT_KEYWORDS=" ARCH", alors tapez ce qui suit :

$ echo app-portage/eix >> /etc/portage/package.keywords

Puis installez le paquet :

$ emerge -av app-portage/eix

Maintenant il va falloir créer l'index et c'est là qu'eix fait toute la différence :

$ time update-eix
 Updating eix database in /var/cache/eix
 Using portage cache: /usr/portage/metadata/cache/
 Reading categories
 Reading masks
 Reading metadata cache
 [app] [dev] [games] [gnome] [gnustep] [kde] [mail] [media] [net] [rox] [sci] [sec] [sys] [www] [x11] [xfce]
 Reading portage overlays
 [/usr/local/portage/entropie/]
 Database updated successfully. 8930 packages.
 eix -u 1,40s user 1,22s system 27% cpu 9,487 total

[titre2]Utilisation[/titre2]

Pour mettre à jour l'index, après un emerge sync par exemple :

$ update-eix

Pour rechercher un paquet :

$ eix -s -c sftp
 Search results: 2
 [ N] dev-perl/net-sftp (no): Secure File Transfer Protocol client
 [ I] net-ftp/vsftpd (2.0.1 ): Very Secure FTP Daemon written with speed, size and security in mind

La même en mode verbeux :

$ eix -s sftp
 Search results: 2
 * dev-perl/net-sftp
 Available versions: 0.05 0.08
 Installed: no
 Homepage: http://search.cpan.org/~drolsky/Net-SFTP-0.08
 Description: Secure File Transfer Protocol client
 
 * net-ftp/vsftpd
 Available versions: 1.0.1-r1 1.2.0-r1 1.2.1 1.2.2 ~2.0.1
 Installed: 2.0.1
 Homepage: http://vsftpd.beasts.org/
 Description: Very Secure FTP Daemon written with speed, size and security in mind

[titre1]Options en détails[/titre1]

[titre2]Mise à jour du cache[/titre2]

update-eix va mettre à jour votre fichier de cache d'eix

Avant que vous puissiez tester toutes les fonctionnalités d'eix, il est absolument nécessaire de mettre à jour ou de créer le fichier de cache d'eix. La mise à jour rassemble toutes les informations sur les paquets dans l'arbre portage officiel et aussi dans votre arbre si vous en avez un. Vous devez re-exécuter cette commande à chaque fois que vous faites un emerge —sync.

L'option —exclude-overlay exclut votre arbre secondaire

Avec cette option que vous appliquerez sur la commande update-eix, il exclura votre arbre secondaire (ou non-officiel). C'est utile pour les développeurs qui utilisent le portage CVS pour qu'il n'y ait pas de doublons d'ebuilds (même version).

[titre2]Recherche[/titre2]

Choix d'opération

Par défaut, si vous ne précisez aucune option, eix va rechercher le nom de paquet que vous avez spécifiée. Mais vous pouvez changer son fonctionnement, par exemple, il va rechercher par rapport à la description que vous avez précisée. Vous pouvez donc changer de cible avec ces options :

-s ou —name : Recherche normale, c'est-à-dire en précisant le nom
-S ou—description : Recherche par la description d'un paquet
-C ou —category : Recherche par le nom de la catégorie du paquet
-A ou —category-name : Recherche par le nom de la catégorie (pas forcement juste) et le nom du paquet (pas forcement juste), exemple : eix -A "games.*/shoot"
-H ou —homepage : Recherche par le site du paquet, par exemple : eix -H sourceforge
-L ou —licenses : Recherche par la licence du paquet, par exemple : eix -L GPL

Algorithmes de recherche

Eix fournit des manières multiples pour rechercher des paquets :

-r ou —regex : Cette option est utilisée par défaut. L'expression réguliére est utilisée, par exemple : eix -r lightenment. Il trouvera le paquet enlightenment.
-p ou —pattern : Elle va rechercher exactement ce que vous lui demandez. Par exemple si vous cherchez kdebase et vous oubliez le "e" à la fin, eix ne trouvera rien.
-f ou —fuzzy [fuzzyness] : Si vous ne savez pas exactement comment le paquet s'écrit, utilisez cette option. Il faut aussi préciser un nombre. Plus le nombre est grand, plus il va vous sortir de résultat. Exemple : eix -f4 motsillah, vous aurez comme résultat : mozilla.

Influencer le rendement

Il y a actuellement 8 paramètres pour commander le rendement d'eix :

-q ou —quiet : aucun rendement, silencieux
-n ou —nocolor : désactive la couleur
-c ou —compact : résultat compacte
-v ou —verbose : inverse de l'option -c, mode verbeux
-l ou —versionlines : chaque version est indiqué sur une ligne

Formats

—format : format normal
—format-compact : format compact
—format-verbose : format verbeux

Une corde de format peut contenir des variables de propriété de paquet, des couleurs et des caractères spéciaux.

Propriété des paquets

: catégorie
: nom du paquet
: versions disponibles
: versions installées
: site web
: licences
: si le paquet est installé "I" sinon "N"
: si toutes les versions sont dans le même arbre cela augmente "[overlaykey]"

Couleurs

Syntaxe : (couleur,luminosité)

Les couleurs disponibles sont : default, black, red, green, yellow, blue, purple, cyan, gray

Exemple : (red,1)

Caractéres spéciaux

\n : nouvelle ligne
\r : retour de chariot
\t : tabulation
\\ : antislash

Conclusion - Exemple de Format

--format "(white,1)<category>/<name>(default): <availableversions>\n\tVersions installées: (yellow,1)
 <installedversions>\n\t(blue,1)Site Web: (green)<homepage>\n"

Pour ne pas retaper le format à chaque fois que vous voulez utiliser eix, vous pouvez le mettre dans le fichier /.eixrc ou faire une aliase comme ceci :

$ alias eix='eix --format "..."'

Vous pouvez même placer cette aliase dans le fichier /.bashrc pour qu'il soit appliqué à chaque fois.

SPLAT : Simple Portage Log Analyzer Tool

max — 2005-12-08T18:33:34Z

[titre1]Introduction[/titre1]

Portage dispose d'un fichier log où est inscrit toutes les manipulations d'emerge. Il se situe dans /var/log et s'appelle emerge.log.

1099140335: === (2 of 9) Compiling/Merging (media-libs/tiff-3.7.0::/usr/portage/media-libs/tiff/tiff-3.7.0.ebuild)
 1099140466: === (2 of 9) Post-Build Cleaning (media-libs/tiff-3.7.0::/usr/portage/media-libs/tiff/tiff-3.7.0.ebuild)
 1099140466: >>> AUTOCLEAN: media-libs/tiff

De vu, comme ça, ce n'est pas très pratique à décoder, c'est pourquoi splat a vu le jour. C'est un analyseur du fichier log d'emerge (comme ci-dessus). Comme son nom l'indique, il lit le fichier, et le retranscrit en informations plus lisibles. Vous donnez un nom d'un paquet installé, et splat vous dit quand il a été emergé, et combien de temps portage à mis pour l'installer. Il fonctionne toujours avec le fichier /var/log/emerge.log. Il a un peu prés la même fonction que genlop.

[titre1]Installation[/titre1]

Le paquet est intégré dans l'arbre portage officiel. Il suffit donc d'utiliser la commande emerge :

$ emerge -av app-portage/splat

[titre1]Options de SPLAT[/titre1]

Pour exécuter le programme, la commande est : splat. La syntaxe à respecter : splat [OPTIONS] paquet. Si vous précisez la catégorie du paquet (catégorie/paquet), splat mettera forcement moins de temps pour le trouver.

Plusieurs options intéressantes :

[titre2]—summary ou -s[/titre2]

L'option indique en quelques lignes :

combien de fois le paquet choisi a été installé,
le temps totale,
le temps moyen,
la première fois qu'emerge l'a construit,
et la dernière version installée.

[titre2]Exemple[/titre2]

$ splat --summary net-www/mozilla
 Total Builds: 8
 Time Elapsed: 5 hours, 41 minutes, and 43 seconds
 Average Time: 42 minutes, and 42 seconds
 
 First Build: net-www/mozilla-launcher-1.18
 (mar aoû 24 16:00:30 2004)
 
 Last Build: net-www/mozilla-firefox-1.0_rc1
 (ven oct 29 15:22:16 2004)

[titre2]—logfile ou -f[/titre2]

Par défaut SPLAT lit le fichier /var/log/emerge.log. Cette option sert à définir un autre fichier que celui par défault.

[titre2]Exemple[/titre2]

$ splat -f /home/maxime/fichier_log_emerge.log

[titre2]—colored ou -c[/titre2]

SPLAT indique le résultat en couleur.

[titre2]—list ou -l[/titre2]

L'analyseur affiche la liste des versions du paquet installé.

[titre2]Exemple[/titre2]

$ splat --list kde-i18n
 kde-base/kde-i18n-3.3.0
 kde-base/kde-i18n-3.3.1

[titre2]—count ou -u[/titre2]

Elle sert à limiter le nombre de reponses. Elle prend en compte que les premiéres réponses.

[titre2]Exemple[/titre2]

$ splat -u 3 --package kde
 
 * dev-util/kdevelop-3.1.0
 
 Emerged at: mer aoû 25 22:06:06 2004
 Build time: 1 hour, 11 minutes, and 36 seconds
 
 * kde-base/kde-3.3.0
 
 Emerged at: sam sep 11 20:55:33 2004
 Build time: 7 seconds
 
 * kde-base/kde-3.3.1
 
 Emerged at: jeu oct 21 15:14:46 2004
 Build time: 15 seconds

[titre2]—package ou -p[/titre2]

L'option indique :

toutes les versions installées d'un paquet,
pour chaque version, indication du temps de la construction,
et la date et l'heure du lancement de l'installation.

[titre2]Exemple[/titre2]

$ splat --package openoffice
 
 * app-office/openoffice-1.1.2
 
 Emerged at: dim sep 12 13:51:57 2004
 Build time: 5 hours, 8 minutes, and 53 seconds

[titre2]—sort ou -t[/titre2]

Elle sert à trier les réponses :

soit par date (le plus vieux au plus jeune) : argument \'date\',
soit par le temps de construction (du plus rapide au plus lent ) : argument \'time\',
soit par le nom (ordre alphabétique) : argument \'name'.

[titre2]Exemple[/titre2]

$ splat -t 'name' kde
 
 * kde-base/kde-3.3.1
 
 Emerged at: jeu oct 21 15:14:46 2004
 Build time: 15 seconds
 
 * kde-base/kde-env-3-r3
 
 Emerged at: jeu aoû 26 12:29:31 2004
 Build time: 12 seconds
 
 etc...etc...

[titre2]—reverse ou -r[/titre2]

La dernière option affiche le résultat à l'envers de la réponse normale.

La magie de Portage

max — 2004-11-24T20:45:00Z

Cet article vous présente une façon de manipuler les informations venant du fichier /var/log/emerge.log avec l'outil genlop qui est, bien sur, indépendant de Portage. On peut trouver par exemple, le temps que mettra la compilation d'une application grâce à cet outil.

[titre1]Introduction[/titre1]

Le fichier /var/log/emerge.log est bien connu pour la centralisation des informations sur les manipulations que vous faites avec emerge. Mais ce qui est moins connu, c'est ce que peut apporter ce fichier quand on le regarde de plus près.

Par exemple, quand vous lancez une mise à jour, vous ne savez pas combien de temps durera la compilation. Vous ne vous rappelez peut-être pas combien de temps à mis le paquet firefox pour emerger... et pourtant Portage, lui, le sait avec le fichier énoncé ci-dessus.

Vous pouvez l'analyser manuellement, mais ce travail est très fastidieux. Heureusement, un outil existe pour cette fonction, il se nomme genlop.

[titre1]Installation[/titre1]

Avant de l'installer avec la commande habituelle, emerge, nous allons devoir le démasquer par le keyword pour utiliser une version notée instable par Gentoo, mais qui ne présente aucun danger et qui possède même des avantages, notamment dans les fonctionnalités.

# echo app-portage/genlop ~x86 >> /etc/portage/package.keywords

Et ensuite, il suffit de l'installer :

# emerge app-portage/genlop

[titre1]Utilisation de genlop[/titre1]

Aprés avoir installé genlop, je vais décrire quelques utilisations de genlop très utiles :

[titre2]Connaître le temps approximatif d'une mise à jour[/titre2]

# emerge -up world | genlop --pretend
 
 [ affichage des paquets à mettre à jour ]
 
 These are the pretended packages: (this may take a while; wait...)
 
 * media-libs/tiff
 * app-sci/stellarium
 * app-arch/gzip
 * dev-libs/libIDL
 * net-www/mozilla-firefox
 * sys-boot/lilo
 * app-doc/abs-guide
 * app-arch/unarj
 * x11-base/xorg-x11
 * app-emulation/wine
 
 Estimated update time: 4 hours, 38 minutes.

Attention, genlop ne donne pas une estimation pour tous les paquets. Voici un exemple, où genlop le signale :

# emerge -up system | genlop --pretend
 These are the pretended packages: (this may take a while; wait...)
 
 [ebuild U ] app-arch/gzip-1.3.5-r3 [1.3.5-r2]
 [ebuild U ] sys-apps/module-init-tools-3.1 [3.0-r2]
 
 !!! Error: couldn't get previous merge of module-init-tools; skipping...
 !!! Error: module-init-tools never merged; estimated time unknown.

Les temps donnés ne sont qu'une estimation et une moyenne, et peuvent ne pas refléter complètement la réalité, si vous utilisez la fonction CCACHE, ou de nouvelles fonctions...etc. Il y a donc un grand nombre de facteurs que que vous devrez prendre en compte.

Une autre option de genlop qui peut être très utile est —current. Elle vous donne le temps de fusionnement du paquet qui est en train de se compiler.

# genlop --current

Bien sur, si vous exécutez la commande, et que les processus de compilation n'existent pas, il vous renvoie :

!!! Error: no working merge found.

Ccache

Stephane Malinet — 2004-10-24T13:45:00Z

Ccache est un outil inclu dans le système de paquets Portage. Il agit comme un cache pour le compilateur. Il accélère les instructions du Makefile ce qui diminue considérablement le temps de la compilation.

Ccache est un cache compilateur pour le C/C++. Il permet lors de la recompilation de paquet de gagner du temps puisqu'il va détecter les portions de C/C++ qui se trouvent dans son cache et ainsi vous éviter de les recompiler (gain de temps).

[titre1]Installation[/titre1]

Pour installer ccache, tapez :

# emerge -av ccache

ensuite tapez « y » ou « yes » et « enter ».

[titre1]Configuration et utilisation[/titre1]

Depuis la version 2.0.48 de Portage, le FEATURES=ccache n'est plus nécessaire, car implémenté. Donc, il ne reste plus qu'à spécifier la taille maximum qu'aura ccache pour stocker les compilations sur le disque dur. Pour ce faire, il faut éditer le fichier /etc/make.conf :

# vim /etc/make.conf

ou (si vous n'avez pas vim d'installé) :

# nano -w /etc/make.conf

et insérez-y la ligne suivante pour un cache maximum de 4Go et pour le repertoire par défaut de ccache(...) :

CCACHE_SIZE="4G"
 CCACHE_DIR="/var/tmp/ccache"

ensuite, pour voire si ccache est fonctionnel et ses statistiques, tapez :

# ccache -M 4G
 # ccache -s

là, apparaîtra quelque chose comme ça :

cache hit 0
 cache miss 0
 files in cache 0
 cache size 0 Gbytes
 max cache size 4.0 Gbytes

Attention, une chose importante : le répertoire par défaut de ccache est /var/tmp/ccache, donc assurez-vous d'avoir fait une partition suffisament grande ! Sinon, une autre possibilité est de modifier le répertoire de ccache. Personnellement, j'ai créé une partition spécialement pour lui que je monte en /ccache.

Voilà... Votre ccache est pret... Il y a, bien sûr, d'autres options possibles que je vous laisse découvrir sur le site officiel en anglais.

Enotice

max — 2004-04-10T17:10:00Z

Enotice est un utilitaire pour Portage. Il sert à enregistrer les messages qu'affichent le système de paquets à la fin de la compilation.

Dans cette article, vous trouverez comment installer, configurer et utiliser cet utilitaire à Portage.

[warn]Cette article est obsolete. Regardez du coté de elogv[/warn]

[titre1]Introduction[/titre1]

Enotice est un utilitaire pour Portage. Il sert à enregistrer les messages qu'affiche le système de paquets à la fin de la compilation .

Par exemple, vous avez une mise à jour importante de 100 paquets, vous n'allez pas regarder à chaque fois qu'un paquet est installé les messages pour l'executer ou le configurer.

[titre2]Exemple de notice[/titre2]

* You need to copy pak0.pk3 from your Quake3 CD into /opt/quake3/baseq3.
 * Or if you have got a Window installation of Q3 make a symlink to save space.
 * To start a dedicated server, run
 * /etc/init.d/q3ded start

Les notices seront stockées dans un répertoire que nous définirons aprés avoir installé le script enotice. Vous pourrez donc les consulter à partir de celui-ci.

[titre1]Installation[/titre1]

Il n'existe pas d'ebuild officiel pour enotice, on ne va donc pas pouvoir l'installer via portage. Il va donc falloir se contenter de l'installer autrement.

Il existe deux maniéres :

Soit modifier le code de Portage, c'est-à-dire qu'on va patcher le fichier ebuild.sh contenu dans le répertoire /usr/lib/portage/bin/ :
- patch pour version 2.0.51-r3
- patch pour version 2.0.50-r10

Ou soit utiliser le fichier profile.bashrc que vous metterez dans /etc/portage/profile :

$ mkdir /etc/portage
 $ mkdir /etc/portage/profile
 $ cd /etc/portage/profile
 $ wget http://dev.gentoo.org/~eldad/enotice/profile.bashrc

La deuxième méthode est conseillée car, nous ne modifions pas le système de paquets, c'est-à-dire qu'enotice pourra donc fonctionner sur un grand nombre de versions de Portage. La première méthode se limite à la version 2.0.51-r3.

Une fois que ceci est fait, nous allons maintenant installer le script sur votre système Gentoo :

Télécharger le script : $ wget http://dev.gentoo.org/~eldad/enotice/enotice

Déplacer le dans /usr/bin :

$ mv enotice /usr/bin

Et donner les permissions de l'éxecuter :

$ chmod +x /usr/bin/enotice

Pour finir, il suffit de le configurer en définissant quel répertoire contiendra les notices :

Ouvrez avec votre éditeur préféré /etc/make.conf :

$ vim /etc/make.conf

Définir la variable PORT_ENOTICE_DIR avec le répertoire :

PORT_ENOTICE_DIR = /var/enotice/

[titre1]Utilisation[/titre1]

Maintenant qu'enotice est installé et configuré, il suffit de lancer la commande "enotice" pour l'utiliser :

$ enotice
 Found 1 notices to read.
 
 Notices available:
 1. quake3-1.32b-r3
 
 q)uit - quitter
 s)ort a | t - trier par nom ou par horodateur
 r)ead <num> - lire la notice <num> ("r" est optionnel)
 r)ead <num1> <num2> - lire toutes les notices de <num1> à <num2> ("r" est optionnel)
 r)ead <letter> - lire toutes les notices dont les noms de paquets commencent par la lettre <letter>
 a)ll notices - toutes les notices
 d)elete <num> - supprimer la notice <num>
 p)urge all notices - purger toutes les notices

Pour lire la notice d'un paquet, il suffit de taper le nombre à droite du nom du paquet.