- Présentation d'archlinux -
Warnaud : on va commencer par une micro intro de archlinux
Warnaud : puis des pkgbuilds
Warnaud : ensuite on rentrera dans le vif du sujet
Warnaud : Archlinux est un fork de crux, à la base c'est Judd Vinet qui a créé cette distribution
Warnaud : Crux et Arch ont le même système d'init que BSD
Warnaud : pas de /etc/init.d toussa c'est tout dans rc.d
wain : crux et arch ont en commun aussi le fichier rc.conf
wain : rc.conf permet de paramétrer les variables d'environnement, les démons et modules à lancer
Warnaud : c'est une distrib optimisée pour les processeurs i686 (32bit) et il 'ya aussi une version 64bits
Warnaud : la distribution essaie de rester simple et de suivre le principe KISS (SC -Keep It Short & Simple)
Warnaud : donc comme le disait wain, y'a pas énormément de fichiers de configuration, la majeure partie des options étant dans /etc/rc.conf
Warnaud : ils ont développés le gestionnaire de paquet “pacman” (pour package manager)
Warnaud : et pacman .. il mange des paquets (packages = pkg), qui sont créés à partir des pkgbuilds dont on va parler
- Les paquetags archlinux -
wain : pour expliquer un peu le principe de paquets d'abord,
wain : disons que arch permet d'installer des paquetages dits “binaires”
wain : c'est à dire qu'ils sont précompilés pour l'utilisateurs
wain : chaque programme est donc compilé avec les options choisies par les mainteneurs, et optimisé pour l'architecture i686 et/ou x86_64
wain : ce n'est qu'un nom de fichier .pkg.tar.gz
Warnaud : le format des paquet, c'est du tar.gz
wain : on peut renommer un paquetage en asyouwant.tar.gz
Warnaud : les pkg sont de la forme : nom-version-release.arch.pkg.tar.gz depuis pacman 3
wain : donc ce programme que les devs d'archs ont compilés et empaquetés dans un fichier .pkg.tar.gz
wain : ce programme ou paquetage est placé sur un dépôt
wain : donc ces dépôts (ftp ou http) contiennent les paquetages officiels, binaires (compilés/optimisés)
wain : sur les dépots extra/current/community, les paquetages sont nommés nom-version-release.pkg.tar.gz
wain : mais quand on crée un paquetage avec makpekg, il crée un fichier nom-version-release-architecture.pkg.tar.gz
Warnaud :
http://mir2.archlinuxfr.org/archlinux/current/os/i686/ « démo
wain : les devs prennent la peine de renommer les fichiers qui sont sur les dépots officiels
wain : donc, pour revenir à archlinux de manière plus générale:
- Les dépôts de paquetages et le Rolling Release System -
wain : Plusieurs dépôts officiels sont proposés:
wain : [current] c'est le dépot des paquetages stable (pas de troll)
wain : la différence entre arch et d'autres distros, c'est que cette branche stable évolue en permanence.
wain : Sous arch, on ne peut pas rester avec une version donnée, fixée dans le temps
wain : on installe une voodoo, duke, 2007.5 ou je ne sais quoi, ça reste les mêmes paquetages
wain : l'intérêt c'est qu'on a pas à subir une grosse mise à jour tous les 6 mois
Warnaud : en gros t'as jamais besoin de réinstaller c'est tout le temps à jour
wain : les fichiers de conf ne sont pas écrasés en général
Warnaud : non il s'ont placés à cotés en .pacnew ou alors s'ils sont remplacés, il sont sauvé en .pacsav
wain : il y a peu de mise à jour dans la conf et ça ne nécessite pas trop d'intervention de l'utilisateur
wain : on pourra décrire plus tard le système de mise à jour des fichiers de conf
wain : c'est un élément important dans la création des PKGBUILDs
Warnaud : faut faire attention en fait, trop de mises à jour peut tuer la mise à jour mais aussi des grosses mises à jour tous les 2-3 mois c'est pas conseillé non plus
wain : c'est bon pour tout le monde pour le Rolling System ?
wain : ok donc pour résumer, si aujourd'hui Rolling Syi on est en version duke, à la prochaine mise à jour, on passera peut-être à la nouvelle version sans réinstaller quoi que ce soit
wain : les versions sont là pour différencier les images de CDROM en gros
wain : donc ça c'était pour le dépot [current]
wain : [current] ⇒ paquetages de base (noyau, system d'init etc…)
wain : ensuite il y a le dépot [extra] qui contient les applications moins vitales (mais importantes): kde/gnome etc…
wain : trop de paquetages étaient dans [extra]
wain : donc c'était trop de travail pour les développeurs
wain : il a été décidé de 'sortir' de nombreux paquetages d'[extra] pour un autre dépot: [community]
wain : [community] est un dépot un peu spécial, puisque les paquetages sont maintenus sur AUR (Arch User Repository) par des utilisateurs
wain : AUR c'est deux choses:
wain : 1. un dépôt de paquetages binaire (i686 et x86_64)
wain : 2. un espace d'échange des fichiers PKGBUILD
wain : nous reviendrons plus tard sur les PKGBUILD
wain : donc community est auto-géré par des utilisateurs dits de confiance ⇒ TU (Trusted Users)
wain : on y retrouve le plus grand nombre de paquetages
wain : (1490)
wain : au passage, le dépot de pkgbuild AUR Unsupported en contient 5000
wain : il reste deux dépôts officiels
wain : [unstable] contient non pas la version instable d'archlinux, mais un petit nombre de paquetages, généralement dans leur version de développement
wain : c'est les paquetages -cvs ou -svn ou -git (souvent)
Warnaud : yes dans des branches qui sont décrites par les développeurs de ces logiciels comme “unstable”
Warnaud : pas toujours :p
wain : eh oui, c'est pas toujours unstable
wain : on donne quelques exemples de paquetages ?
wain : vim-devel, xaralx
wain : bitlbee-devel
Warnaud : gimp-devel
Warnaud : fvwm-devel
wain : compiz-git mais pas compiz
wain : donc faut bien comprendre que ce dépôt ne met pas en danger votre distribution
wain : C'est bon pour [unstable] ?
wain : on continue sur [testing] ?
Warnaud : mais il est pas obligatoire non plus [current] / [extra] / [ community] ça suffit largement pour avoir une distro über à jour
wain : il faut comprendre que testing n'est pas un dépot comme extra ou community ou unstable
wain : c'est une *branche*
wain : dans testing, vous trouverez des paquetages déjà présents dans [current], mais dans des versions plus récentes
wain : le but de cette branche est donc de tester les paquetages de [current]
wain : attention, [testing] ne remplace pas complètment [current], si vous activez testing, il faut garder current aussi
wain : testing contient au max 40 à 50 paquetages
Warnaud : testing c'est super chaud surtout si tu sais pas réparrer les conneries qui pourraient se produirent
- Configurer pacman -
wain : la transition est toute faite, parlons du pacman.conf ?
Warnaud : pacman prends le premier pkg qu'il trouve
Warnaud : pas forcément le plus haut en version / release
wain : et cet ordre de priorité, il est défini par l'ordre de configuration des dépot dans le /etc/pacman.conf
Warnaud : si testing est avant current/extra/community, ça prendra forcément dans cet ordre,
wain : il serait parfaitement inutile de mettre current en n°1 et testing en n°2
Warnaud : sinon faut le dire explicitement lors de l'install d'un pkg: exemple : pacman -S testing/massacre
wain : Vous savez maintenant qu'on peut avoir plein de paquetages binaire avec testing/extra/current/community et unstable
wain : mais vous me direz que ça fait pas encore beaucoup de paquetages
wain : et la force d'archlinux est que son système de construction de paquetages est si simple, que des milliers (voir millions) de personnes proposent leurs propres paquetages
wain : archlinux a cette particularité de ne proposer qu'une seule version d'un paquetage
wain : les chiffres sont faussés sur les autres distros
wain : et à l'usage on voit bien que même une distro comme gentoo a beaucoup de paquetages manquants par rapport à archlinux
- La construction d'un paquetage -
wain : bon, attaquons la partie construction d'un paquetage
wain : vous avez sans doutes vu un jour que pour distribuer un programme, il doit en général être compilé
wain : la compilation se fait en générale avec 3 commandes:
wain : ./configure
wain : make
wain : make install
wain : on utilise ces trois commandes pour installer à partir des sources la majorité des logiciels sous linux
wain : mais un paquetage archlinux, c'est un fichier (pkg.tar.gz) qui contient déjà ce programme précompilé
- Makepkg et le PKGBUILD -
wain : pour créer ce paquetage, archlinux dispose d'un outil: *makepkg*
wain : mais pour se facilité la vie, on va enregistrer toutes les infos dont on a besoin pour télécharger les sources du programme, compiler, et vérifier dans un script: le pkgbuild
Warnaud : c'est le fichier central dans la compilation d'un pkg
Warnaud : c'est lui qui pilote toute la compilation même si certains fichiers peuvent se rajouter à cotés
wain : le PKGBUILD contient en vrac: le nom du logiciel, la version, l'endroit où télécharger les sources, les commandes à taper pour le compiler
Warnaud :
http://archlinux.fr/repoviewer/index.ph ... d=calcurse «< exemple de pkgbuild “simple”
Code : Tout sélectionner
pkgname=NOM
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=(i686 x86_64)
url=""
license=""
depends=()
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
install=
source=($pkgname-$pkgver.tar.bz2)
md5sums=()
build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr
make || return 1
make DESTDIR=$startdir/pkg install
}
wain : donc pour construire un paquetage, il faut d'abord écrire ce script PKGBUILD
wain : vous avez remarqué surement que le language ici est le bash
wain : c'est à dire la même syntaxe que les commandes que vous tapez dans votre terminal
wain : on ne peux pas faire plus simple (KISS)
wain : cette partie là est directement pompée encore une fois de crux
- Détail d'un PKGBUILD -
wain : on se détaille un pkgbuild ligne par ligne ?
wain : remarque: pour ceux qui resteront jusqu'à la fin, nous aborderons les autres moyens de faire des paquetages (sans écrire de PKGBUILD)
wain : ok on part sur le PKGBUILD de calcurse
wain : pkgname=calcurse
wain : pas de commentaire: c'est le nom du programme. Il doit etre en minuscule, sans espace
wain : pkgver=1.8
wain : c'est la version du programme
wain : parfois la version sera “2.2beta” donc les lettres sont acceptées
wain : mais les tirets sont interdits
wain : pkgrel, c'est le numéro de release du paquetage
wain : ça veut dire que ce numéro n'a absoluement rien à voir avec le programme à empaqueter en lui même
wain : par exemple, un client mail comme sylpheed dépend de openssl
wain : à chaque fois que openssl est mis à jour, il faut que le mainteneur recompile sylpheed
wain : il incrémente donc pkgrel
solsTiCe : hein et les lib ca sert à quoi ?
solsTiCe : librairies , bibliothèque
wain : bein les libs openssl se mettent à jour, donc il faut recompiler les paquetages qui en dépendent
wain : c'est comme ça
wain : heureusement, c'est pas le cas pour tous les paquetages
marc[i1] : après viens pkgdesc=”“
marc[i1] : Quand vous créez une description pour un paquetage, veiller à ne pas inclure le nom du paquetage en référence. Par exemple, “Nedit is a text editor for X11” doit être simplifié en “A text editor for X11”. Essayez aussi de faire une description d’environ 80 caractères.
wain : ensuite,
wain : url=“
http://culot.org/calcurse/“
wain : license=“GPL“
wain : l'url c'est pratique
marc[i1] : Ce champ contient l’URL optionnel qui peut être associé avec l’empaquetage. C’est simplement l’adresse internet officiel du projet.
wain : quand on cherche avec pacman un programme, on voit tout de suite l'url du site pour regarder les captures d'écran par exemple
marc[i1] : viens le champs license=”” ! lourd dossier !!
marc[i1] : Ce champ précise la licence du paquetage. Les licences les plus utilisées sont dans /usr/share/licenses/common. Si vous voyez la licence du paquetage ici, faites en simplement référence dans le champ de la licence (ex: license=(’GPL‘)). Si le paquetage est distribué avec une licence non trouvé dans /usr/share/licenses/common, vous devrez inclure la licence dans le paquetage et renseigner license=(”custom”) ou license=(”custom:LicenseName”). La licence doit être placé dans $startdir/pkg/usr/share/licenses/$pkgname lors de la construction du paquetage. Si plusieurs licences sont applicables pour le paquetage, lister les toutes : licenses=(’GPL’ ‘FDL‘).
capnemo : tiens au fait ca me penser que arch viole la gpl
Warnaud : come la plupart des distros
capnemo : bah une distro qui distribue un paquet binaire doit fournir le source avec .. ou fournir une adresse ou pdt 3 ans on peut le recuperer
Warnaud : ouais c'est un pb ça capnemo
Warnaud : car à cause de ça on peut pas se recompiler certains pkg
Warnaud : je continue
Warnaud : Précise le fichier spécial d’installation qui n’est pas inclus dans le paquetage. Celui ci est dans le même répertoire que le PKGBUILD et sera copié dans le paquetage par makepkg. Il n’est pas nécessaire de l’inclure dans la variable source. (ex : install=pkgname.install).
Warnaud :
wain : notez qu'arch fournit des paquetages non libres et commerciaux contrairement à d'autres distros
Warnaud : en fait il est possible, en plus du fichier PKGBUILD d'avoir des fichiers annexes dont le fichier install
marc[i1] : Pacman a la faculté de conserver et d’exécuter des scripts spécifiques par paquetage quand il installe, désinstalle ou met à jour un paquetage. Cela permet au paquetage de se configurer tout seul après l’installation et de faire exactement le contraire lors de sa désinstallation.
marc[i1] : d'où l'utilisation du fichier .install
capnemo : ou de foutre la merde partout
Warnaud : pratique sur des pkg un peu douteux ou quand il y'a du y'avoir pas mal de modifications
capnemo : genre rm -rf ${plop}/ et plop et pas defini ^^
wain : on explique un peu ça ?
wain : un paquetage, on disait plus haut que c'est une archive au format .tar.gz
wain : lorsqu'on installe un paquetage, on ne fait que décompresser cette archive
marc[i1] : La manière dont s’exécute chaque opération dépends de chaque opération :
Code : Tout sélectionner
pre_install
script lancé avant l’extraction des fichiers.
post_install
script lancé après l’extraction des fichiers.
pre_upgrade
script lancé avant l’extraction des fichiers.
post_upgrade
script lancé après l’extraction des fichiers.
pre_remove
script lancé avant la suppression des fichiers.
post_remove
script lancé après la suppression des fichiers.
Pour utiliser cette option, vous devez créer un fichier ‘pkgname.install’ et mettez le dans le même répertoire que le script PKGBUILD. Utilisez la variable install :
install=pkgname.install
Le script install n’a pas besoin d’être spécifié dans le champ source. Un modèle de fichier install est disponible dans l’arborescence ABS (/var/abs/install.proto).
Warnaud : (NOTE: c'est pour les logiciels spéciaux, 90% du temps y'a pas besoin de tout ça, un simple fichier PKGBUILD suffit)
wain : je disais avant le flood que le paquetage c'est qu'une archive décompressée
wain : mais le fichier .install va permettre de lancer une commande au moment de l'installation
wain : par exemple, si on installe un paquetage qui fournit une police
wain : la police est en place sur le système mais pas enregitrée
wain : le fichier .install va alors lancer une commande pour mettre à jour la liste des polices
wain : pas dans le pkgbuild directement
wain : le pkgbuild n'est jamais distribué avec le paquetage
marc[i1] : et tu précise dans le PKGBUILD si tu as un fichier install !
wain : toutes les commandes qui sont dans le pkgbuilds sont exécutés par le créateur du paquetage
wain : seul le fichier .install est fournit avec le paquetage aux utilisateurs
wain : bon on continue avec les dépendances ?
wain : pour compiler un programme, on a besoin de dépendances
wain : exemple: pour compiler the gimp, il faut gtk
wain : ces dépendances sont donc notées dans le pkgbuild
marc[i1] : Une liste de paquetages pour lesquels dépends le paquetage compilé et installé. Les paquetages dans cette liste doivent être entourer de simple guillemet et doivent contenir au moins le nom du paquetage. Vous pouvez aussi inclure la version requise sous cette forme : ‘nom<>version’, quand <> est un des trois comparateurs : >= (supérieur ou égal à), ⇐ (inférieur ou égale à), or = (égal à).
wain : oui on peut parfoit utiliser les > = et <
wain : c'est surtout pour dire que gimp version 2.x à besoin au minimum de gtk 2.y
wain : c'est une gestion très simplifiée et vraiment minimaliste
wain : cela facilite l'élaboration des paquetages biensur
wain : plus généralement, archlinux ne gère pas les dépendances comme les autres distributions
wain : vous connaissez tous le format rpm par exemple
wain : ces formats rpm ou deb, indiquent précisémment quelle version de chaque librairie est nécessaire au fonctionnement du programme
wain : autre point sur les formats type rpm:
wain : pour un programme donné, il faut indiquer dans le rpm la liste de *TOUTES* les dépendances requises
wain : archlinux est très souple sur ce point
wain : deux points sont totalement différents:
wain : 1. on indique presque jamais quelle est la vestion de la librairie nécessaire
wain : cela évite que les mises à jour soient bloquées à cause de conflits de versions
wain : 2. les dépendances ne sont pas toutes citées dans le pkgbuild
wain : on utilise les dépendances en cascade
wain : j'explique les deps en cascade:
wain : le paquetage de firefox ne fonctionne que si xorg est installé
wain : mais firefox a aussi besoin de gtk
wain : or gtk lui même nécessite xorg
wain : donc dans le PKGBUILD de firefox, on dit simplement que la dépendance c'est gtk
wain : et pacman en déduit que xorg est nécessaire
wain : ça parait logique, mais les autres distributions ne fonctionnent pas comme ça
melodie : exemple spécial : firefox = pkgbuild particulier…
wain : je parlais de firefox parcque tout le monde connait
wain : on reste sur l'exemple de calcurse pour la suite
Warnaud :
http://archlinux.fr/repoviewer/index.ph ... d=calcurse
wain : il y a 2 niveaux de dépendances dans le pkgbuild
wain : depends indique les programmes nécessaire à l'exécution du logiciel qu'on va distribuer aux utilisateurs
wain : makedepends indique les programmes nécessaires uniquement au mainteneur qui compile le programme
wain : les programme et librairies décrites dans makedepends peuvent être supprimées après la compilation
wain : C bon pour les dépendances ?
Warnaud :
http://archlinux.fr/repoviewer/index.ph ... planfacile « exemple de soft avec makedepends, awk est nécessaire pour la compile mais pas forcément après
Warnaud : en fait ces dependances sont souvent indiqués dans les docs des programmes/libs que l'on compile et si on en loupe, soit ça compile pas, soit certains outils qu'on verra plus tard sont pas content
wain : ok on passe la variable arch=('i686')
wain : c'est une variable récente
wain : c'est désormais obligatoire depuis pacman3
marc[i1] : pour le moment seul *deux* architectures sont proposés
vincentxavier : /!\ la variable arch n'a *rien* a voir avec CHOST
vincentxavier : ce n'est qu'une identification des packages
wain : ensuite on a la variable source
wain : ça permet d'indiquer à quelle adresse (http/ftp) on peut trouver les sources du programme, ou un patch
marc[i1] : La ligne source contient les fichiers requis pour la construction du paquetage. Les fichiers sources doivent être dans le même répertoires que le PKGBUILD, sinon ils doivent avoir leur URL complète. Pour faire le PKGBUILD le plus utile possible, utilisez les variables $pkgname et $pkgver si possible lors que vous indiquez l’emplacement du téléchargement.
wain : notez que ces sources sont téléchargées automatiquement et stockées pour plus tard dans un répertoire (indiqué dans le fichier makepkg.conf)
wain : pour vérifier après le téléchargement que les fichiers sont complets, on peut renseigner les checksums
marc[i1] : Ce champ contient le hash MD5 pour tout les fichiers indiqué à la ligne source (dans le même ordre). makepkg va l’utiliser pour vérifier l’intégrité des sources pendant la séquence de construction. Il est facile de générer le md5sums, “makepkg -g » PKGBUILD”. Puis vous éditez le PKGBUILD pour déplacer la variable md5sums situé en fin de fichier à une place plus adaptée. NOTE : makepkg supporte plusieurs algorithmes et leur champ correspondant (sha1sums pour l’algorhytme SHA1). Pour le moment, les paquetages officiels utilisent md5sums uniquement.
melodie : marc[i1] /!\ “makepkg -g » PKGBUILD” : là ça fait quoi le '> >' ?
wain : melodie, ça envoie automatiquement le résultat au bout du fichier
vincentxavier : melodie: le » ca concatène à la fin
zura : ca ajoute le checksum md5 a la fin du PKGBUILD
wain : on peut utiliser les formats suivants: md5, sha1, sha256, sha384, sha512
wain : autre élément du pkgbuild qu'on ne voit pas ici, la variable *”options”*
wain : les options permettent plusieurs choses
wain : retirer ou conserver les docs
wain : utiliser telles ou telles option de compilation (ccache/distcc, makeflags)
marc[i1] : Conserver les fichiers libtool (.la) dans le paquetage. Précisez “!libtool” pour les supprimer.
marc[i1] : Conserver les repertoire vides dans le paquetage.
marc[i1] : Permet d’utiliser un makeflags particulier indiqué dans makepkg.conf pendant la compilation. Plus pratique dans sa forme négative “!makeflags” avec les paquetages qui ont des problèmes de compilation avec les makeflags personnalisés comme “-j2” (ou supérieur).
wain : si la ligne option n'est pas renseignée dans le pkgbuild, les options par défaut sont: OPTIONS=(strip !docs libtool emptydirs)
wain : donc on strip les binaires, on supprime les docs, on conserve les fichiers .la et les répertoires vides
Warnaud : Note : comme on le voit (!docs) y'a pas de docs dans les pkgs arch
marc[i1] : la doc c'est pour les ploucs !
wain : voilà, il n'y a qu'une partie des pages de man
wain : voilà, je pense que toutes les variables du pkgbuild sont décrites
wain : sachez qu'il est possible de les vérifier
wain : grâce à l'utilitaire namcap, qui permet d'étudier un .pkg.tar.gz
wain : et de déceler une erreur dans les md5, dans les dépendances, la licence, etc…
darkhad : melodie, namcap -i nomdupackage.arch.pkfg.tar.gz. ça vérifie si les dépendances indiquées ds le PKGBUILS sont bonnes
Al1 : tout le monde aura compris que namcap est la lecture contraire de pacman
wain : conflicts, ça permet d'indiquer plus tard à pacman, qu'il ne doit pas installer ce paquetage si un autre est déjà présent
marc[i1] : Une liste de paquetage qui entrent en conflit avec ce paquetage (qu’ils ne peuvent pas être installé en même temps). Cette variable répond aux mêmes exigences que la variable depends hormis que vous ne pouvez pas préciser les versions.
wain : provides, ça permet de dire que le paquetage est équivalent à un autre paquetage
marc[i1] : Un choix de “solution virtuel” que fourni le paquetage. Cela permet de fournir un nom de dépendance autre que celui d’un paquetage au nom explicite. Par exemple, le paquetage dcron peut se nommé ‘cron’, tous les paquetages vont dépendre de ‘cron’ au lieu de ‘dcron ou fcron
wain : enfin, replaces
wain : c'est un peu plus dangereux
marc[i1] : C’est une liste de paquetage que le paquetage devrait remplacer, il peut être utilisé pour remplacer des paquetages renommé / retravaillé. Par exemple, si le paquetage nommé ‘j2re’ est renommé ‘jre’, cette directive permet aux futures mise à jour de continuer même si le paquetage est modifié.
vincentxavier : replaces n'est pas à utiliser en règle générale
marc[i1] : replaces na pas lieu d'être utilisé
wain : il faut toujours utiliser conflicts si on utilise replaces
vincentxavier : marc[i1]: oui, c'est dans le cas des changements de nom
wain : il faut bien comprendre que contrairemen à la directive *conflicts*, l'utilisateur n'aura pas d'autre choix avec *replaces* que de supprimer l'ancien pour installer le nouveau
wain : on arrive à build()
- La fonction build: l'exemple de calcurse -
wain : et donc –> build()
wain : c'est le code qui va permettre de faire le paquetage
wain : petit préambule
wain : dans le pkgbuild, il y a une variable importante: startdir
wain : imaginez votre répertoire vide: /tmp/test/
wain : mettez-y le PKGBUILD
wain : dans le PKGBUILD, la variable $startdir aura pour valeur /tmp/test/
Warnaud : en fait toute la compilation du pkg se fait dans un “fakeroot” pour après pourvoir récupérer tout ce qui est créé/compilé et pouvoir le mettre dans un pkg d'où l'utilisation de la variable $startdir
marc[i1] : $startdir = pwd
wain : donc $stardir est le répertoire courant. Deux autres répertoires sont créés automatiquement
wain : 1. $startir/src
wain : 2. $startdir/pkg
wain : src, c'est le répertoire où les sources du programmes sont décompressées (automatiquement)
wain : donc toute la compilation se joue dans ce répertoire src/
wain : je vous proposes de décompresser les sources de calcurse
wain : téléchargez le fichier PKGBUILD dans /tmp/test/
wain : ça sera plus intéressant avec cet exemple
wain :
http://archlinux.fr/os/i686/calcurse/PKGBUILD
wain : bon je vous propose de télécharger les sources et les décompresser grace à la commande: makepkg -o
wain : juste le pkgbuild
wain : puis “makepkg -o”
wain : tout le monde devrait se retrouver avec le fichier PKGBUILD, plus un nouveau répertoire “src”
wain : bon on va regarder le dossier src: “cd src/calcurse-1.8”
wain : là on voit tout le code source du programme
wain : si vous regardez le fichier INSTALL, il contient tout ce dont on a besoin:
wain : 1. `cd' to the directory containing the package's source code and type
wain : 2`./configure'
wain : 3. Type `make' to compile the package.
wain : 4. Type `make install' to install
wain : voilà, on sait quoi mettre dans notre fonction build() !
wain : ou presque
wain : je rappelle qu'il ne faut jamais faire ceci en root !
wain : revenez au dossier $startdir: cd ../..
wain : et regardez le PKGBUILD
wain : 1 ère ligne
wain : la fonction build commence par “cd $startdir/src/$pkgname-$pkgver”
Al1 : ca veud dire qu'on se deplace dans ce fameux dossier qu'on vient d'ouvrir
wain : exactement
wain : lorsqu'on lance makepkg, il va se placer dans le répertoire /tmp/test/src/calcurse-1.8
wain : ensuite, que nous disait le fichier INSTALL ?
wain : configure, make et make install ⇒ on retrouve tout ça dans la fonction build
wain : ”./configure –prefix=/usr”
wain : ça lance la configuration des sources, en indiquant que le programme devra être exécuté dans /usr/
wain : c'est important de comprendre ça
wain : les programmes peuvent êtres installés dans /usr/bin, ou dans /usr/local/bin en fonction des distributions
wain : sour archlinux, le choix a été fait de ne pas utilier /usr/local
wain : donc en forçant prefix=/usr/ le programme ira chercher ses binaires dans /usr/bin, ses datas dans /usr/share/truc, ses libs dans /usr/libs etc..
wain : si on ajoute pas cette option –prefix=/usr, le paquetage sera correct aussi
wain : mais disons que ça ferait désordre
wain : ligne suivante:
wain : “make || return 1”
wain : make, c'est la commande qui compile le programme
wain : si jamais cette commande échoue (la compilation plante)
wain : il ne faut pas que makepkg continue
wain : il faut en cas de plantage que makepkg s'arrête, et la commande return est là pour ça
wain : ça c'est du bash après
wain : une commande renvoie toujours une valeur
wain : (un signal)
wain : c'est 0 si tout va bien
wain : et c'est 1 ou autre si ça se passe mal
wain : le signe || permet de détecter une sortie de code 1
wain : si la commande make renvoi 1, alors la commande située à droite de “||” sera exécutée
wain : le pendant de “||” est ”&&” qui permet d'exécuter une autre commande à condition que la première ait réussi
wain : suite au “make || return 1”, on a le programme tout compilé
wain : dernière étape d'après le fichier INSTALL, faire un “make install” qui a pour but d'installer le programme tout juste compilé sur notre sytème
wain : et là, malgré l'heure tardive, vous dites “NON!”
wain : on ne veut pas installer le programme sur notre système !
wain : on veut juste faire le paquetage n'oubliez pas
wain : si à ce stade on fait un make install (il faudrait être root pour ça), on va copier des fichiers partout sur le disque, et pacman ne saura plus jamais retrouver/mettre à jour/supprimer ces fichiers
wain : donc, on utilise une option pour dire qu'on ne veut pas installer sur le disque, mais dans un paquetage ⇒ DESTDIR, ou prefix
wain : là ça dépend comment est conçu le programme
Mildred : ça dépend des makefiles quand même … mais un bon programme fera en sorte de faciliter la création des packages. Et au pire il faut installer tous les fichiers à la main dans $startdit/pkg
wain : voilà, c'est le cas un peu plus complexe où on doit utiliser des “cp” ou des “install” dans le pkgbuild directement
wain : donc cette option (DESTDIR en général) va permettre de ne pas installer dans le système, mais dans le répertoire $startdir/pkg
wain : soit /tmp/test/pkg dans notre exemple
wain : vous pouvez maintenant lancer makepkg pour voir le résultat
wain : analysons le résultat
wain : =⇒ Removing info/doc files…
wain : ⇒ par défaut, nous disions tout à l'heure que les docs étaient supprimées
wain : =⇒ Compressing, stripping etc… idem
wain : =⇒ Compressing package… tiens, tiens
wain : mais qu'est-ce qu'il compresse ?
wain : ça ne peut être qu'un répertoire
wain : exactly, c'est notre répertoire pkg qui est compressé dans l'archive calcurse-1.8-1-i686.pkg.tar.gz
wain : c'est pas plus compliqué
wain : il reste deux lignes:
wain : =⇒ Generating .FILELIST file…
wain : =⇒ Generating .PKGINFO file…
wain : regardez dans le répertoire /tmp/test/pkg/
wain : il y a deux fichiers .FILELIST .PKGINFO
wain : .FILELIST contient la liste des fichiers du paquetages
wain : usr/bin/calcurse, usr/man/man1/calcurse.1.gz etc…
wain : .PKGINFO contient les infos générales sur le paquetage en lui-même
wain : c'est le résultat de pacman -Si en fait
wain : le nom, la version, la description, le site, la taille, l'architecture, les dépendances, la licence etc…
wain : pacman -Qi donne en plus la date d'installation, la place occupée etc… des choses qu'on ne peut connaitre que si le paquetage est installé
wain : en conclusion: nous avons vu comment faire un PKGBUILD
wain : quel est le processus interne de makepkg qui mène à la création du paquetage
- Outils divers pour les paquetages -
wain : il ne reste qu'à installer avec pacman ce paquetage ou à le distribuer sur un dépot non officiel comme [archlinuxfr]
Warnaud : ou [ton_nom]
wain : on peut aussi partager ce PKGBUILD avec les autres utilisateurs sur aur.archlinux.org
Warnaud : et utiliser l'über outils qui roxor : yaourt
wain : oui, yaourt nous sert par exemple à trouver les PKGBUILDs sur AUR
wain : à les télécharger, les compiler et les installer automatiquement
marc[i1] : Quand vous utilisez makepkg pour construire un paquetage, voilà ce qu’il fait automatiquement :
Code : Tout sélectionner
1- Vérifie si les dépendances du paquetage sont installées.
2- Télécharge les sources depuis les serveurs.
3- Extrait les sources.
4- Appliquer les patchs si besoin.
5- Compile le programme et l’installe dans un répertoire temporaire.
6- Supprime /usr/doc, /usr/info, /usr/share/doc, et /usr/share/info dans le paquetage.
7- Enlève les symboles des binaires des binaires.
8- Enlève les symboles de débuggage des bibliothèques.
9- Génère le fichier méta qui est inclus dans chaque paquetage.
10- Compresse le répertoire temporaire dans le paquetage.
11- Range le paquetage dans le répertoire de destination choisi (cwd par défaut).
wain : quand on sait faire un paquetage, il n'y a plus de limite sur archlinux
marc[i1] :
http://wiki.archlinux.fr/howto:archlinu ... gstandards « le Guide de l'Empaqueteur sous Archlinux
Mildred : maintenant, depuis que j'utilise archlinux, je ne met plus rien dans /usr/local … que c'est agréable. Le système est en plus toujours clean.
wain : le point important c'était aussi la rapidité de pacman par rapport à slackware
Mildred : rapide ???
wain : oui le calcul des dépendances, la vitesse de recherche…
wain : un paquetage sous slackware ça se fait d'une autre manière que sous arch
wain : sous slackware, on va “faire semblant” d'installer le programme
wain : on fait le ./configure et make et make install, et un programme analyse pendant ce temps ce qui se passe
wain : c'est ainsi que les fichiers nécessaire au paquetages sont détectés et empaquetés
marc[i1] : euh je te suis pas là !
marc[i1] : sous Slack c'est comme sous Arch
wain : si je te dis checkinstall
marc[i1] : checkinstall fonctionne pour les .tgz, .rpm et .deb
wain : sachez que sous arch aussi c'est possible grâce à Wocka
wain :
http://www.methylblue.com/wocka/
wain : donc si un paquetage est difficile à faire, et qu'il nécessite un patch, il peut-être utilise d'utiliser wocka, pour faire un vrai paquetage pour pacman
Mildred : au fait, j'ai fait un petit script qui me crée un répertoir au nom du package dont je veux créer le PKGBUILD et qui peut aussi compresser le dossier où se trouve un PKGBUILD en incluant tout ce qu'il faut pour soumettre ça sur AUR, ca intéresse quelqu'un ?
Mildred : mon script :
http://arch.mildred632.free.fr/pkgcreate/
marc[i1] : pour info, ceux qui utilise ViM peuvent utiliser un fichier de syntaxe pour aider à la rédaction :
http://wiki.archlinux.fr/howto:pkgbuild_vimsyntax
wain : ah j'ai aussi un script du genre mildred, pour faire les majs
wain : j'utilise aussi aurup
Grenshad : et il faut quoi pour soumettre sur AUR ?
marc[i1] : Guide de l'Utilisateur sur AUR :
http://wiki.archlinux.fr/howto:archlinu ... rguideline
wain : Autre petite astuce, dans la même veine que wocka:
wain : c'est bpkg qui existe depuis des années et qui fait du bon boulot
wain :
http://swapoff.org/bpkg
wain : bpkg
http://www.rsnapshot.org/downloads/rsna ... 2.1.tar.gz
wain : cette commande télécharge les sources, compile, installe comme un vrai paquetage
darkhad : et les utilisateurs de jedit, deux macro interessantes
- Generate md5sum for sources files in PKGBUILD
- Runs makepkg for the current opened PKGBUILD-file
wain : il y a un truc nommé autopkgbuild ou automakepkgbuild qui fait tout seul un PKGBUILD
wain : + deux ou trois autres programmes qui espionnent l'installation pour recréer le package avec le .filelist correspondant
wain : wocka est plus à jour
XULien : peut on revenir sur namcap qui m'intrique svp?
marc[i1] :
http://xentac.net/~jchu/blog/static/namcap
marc[i1] : While it can look for common errors and warnings, it isn't very smart. For example, the “depends” rule (the most popular namcap rule) uses ldd to map out dependencies. It's good for very simple checking, but should not be blindly trusted.
wain : namcap ne fonctionne que sur un paquetage binaire
wain : il ne fonctionne pas si t'as juste le pKGBUILD
wain : mais disons qu'on peut compiler un paquetage même si on n'indique pas les dépendances
wain : tu compile, t'as ton .pkg.tar.gz
wain : tu passe namcap, l décompresse, teste tous les binaires et cehrche les deps
wain : si une dep manque ou qu'elle est inutile, il gueule
(d'autant que pour une synthèse, c'est très long... )
)
