Club LinuX Nord-Pas de Calais

5- RPM : Faites-le vous même !

Vincent Beuselinck — 2005-01-25T11:34:11Z

outils accessoires et liens

Plusieurs outils sont généralement cités en matière de création de RPM.

Il y a RpmLint dont l'objectif est de vérifier si votre fichier SPEC respecte les règles de l'art. Il vous fournira un rapport très détaillé. De l'essentiel au détail, le nombre de remarques sera conséquent.

Alien est souvent cité car il permet de passer d'un format à un autre assez facilement (de deb à rpm, de tar.gz à deb, inversement, etc).

D'autres outils viennent apporter une interface conviviale à rpm ou simplifient la ligne de commande (kpackage, rpmbuilder...) sans révolutionner le système.

Pour aller plus loin, voici les liens qui nous ont aidé :

http://genetikayos.com/code/repos/r...

http://cvs.mandriva.com/

http://club.mandriva.com/xwiki/bin/KB/

http://club.mandriva.com/xwiki/bin/...

http://rikers.org/rpmbook/

http://c.laloy.free.fr/howtos/linux...

Conclusion

Voilà, la création d'un RPM devrait maintenant être bien moins mystérieuse...

Retour à la 4Úme partie : Des exemples

4- Quelques exemples

Vincent Beuselinck — 2005-01-25T11:33:59Z

exemples vécus

Le RPM du fainéant

Auteur d'un jeu de tarot initialement pour Windows conçu sous Delphi de Borland, j'ai procédé à son transfert vers Linux à l'aide de Kylix (EDI Delphi sous Linux conçu par Borland. Kylix n'est pas libre. Il existe néanmoins une version "open edition" gratuite ).

Dans un premier temps je l'ai diffusé sous la forme d'un tar.gz contenant les binaires et d'un autre contenant les sources. Je me suis alors lancé dans sa eRPéMisation et j'ai éclusé les howtos et autres sites persos sur le thème. Remarquons tout de suite celui de Mandriva (désormais disponible en Français).

Pas grand chose à la portée d'un anglophobe au vocabulaire limité à quelques dizaines de mots.
J'avais néanmoins compris quelques trucs :
– la structure obligatoire des répertoires à mettre en place ;
– l'existence d'un script d'eRPéMisation ;
– la possibilité de "tricher" sur des scripts existants en allant sur le CVS de Mandriva.

1) Les dossiers

Dans votre dossier personnel, vous avez créé les dossiers suivants :

– RPM

RPM/SOURCES où il faut mettre les fichiers sources compressés
RPM/SPECS où il faut créer son fichier de spécifications
RPM/RPMS qui contient un dossier par plateforme
- RPM/RPMS/i586 où sera créé votre RPM pour Pentium
RPM/SRPMS où sera créé le "SRC.RPM" qui permet de refaire le RPM selon la méthode décrite plus bas
RPM/tmp où sera stockée votre application compilée pendant la production du RPM

2) le fichier SPEC

C'est un fichier texte qui définit comment va être créé votre RPM. Celui qui suit est une version “Fainéant” ! Il ne compile rien mais se contente de recopier les fichiers à la manière d'un tar.gz à l'emplacement identique. J'ai fait cela car je n'arrivais pas à maîtriser le compilateur en ligne Kylix (entretemps, je me suis soigné) :

_ %define name bztarot _ %define version 1.01 _ %define release 9 _ Name: %{name} _ Summary: Jeu de tarot a 4 sous environnement graphique _ Version: %{version} _ Release: %{release} _ License: GPL _ Group: Games/Cards _ URL: http://www.beuselinck.com _ Provides: %{name} = %{version}-%{release} _ Source: bztarot-1.01.tar.bz2 _ %description _ Ce jeu de tarot vous permet de jouer seul contre l'ordinateur dans des parties a 4. Respecte la reglementation de la Federation Francaise de Tarot. _ %install _ %post _ %{update_menus} _ %postun _ %{clean_menus} _ %files _ /usr/bin/bztarot-1.01 _ /usr/bin/bztarot _ /usr/lib/libborqt* _ /usr/share/icons/bztarot.png _ "/usr/share/applnk-mdk/More applications/Games/Cards/bztarot.desktop" _ %changelog _ * Mon Oct 12 2004 Vincent Beuselinck <vincent@beuselinck.com> 1.01 _ - ajout d'un écran d'accueil _ - correction d'un bug (sigserv 11) _ - rajout d'une entrée de menu oubliée _ - compatibilité noyau 2.6 _ - aide integrée _ - modifications pour empaquetage RPM

ATTENTION : Ce fichier SPEC n'est pas techniquement un bon modèle : il ne réalise pas la compilation mais se contente de recopier les binaires (Horreur !). L'entrée de menu qu'il crée a des résultats curieux selon les versions de MandrakeLinux

Dans un premier temps, j'avais accentué mes descriptions. Avec les commandes urpmi et (rpm, j'obtenais le résultat escompté mais dans rpmdrake les rubriques avec accent ou cédille disparaissaient. J'ai déposé un rapport de bogue et la réponse a été en substance qu'il fallait faire ça en UTF8 (???) pour que ça marche.

3) "Tricher" sur des fichiers specs existants

Une solution simple pour examiner un fichier SPEC existant est de télécharger le SRC.RPM d'un logiciel et d'en extraire le fichier *.spec.

Personnellement, j'utilise mc , une application "console" qui lit dans les paquetages RPM comme s'il s'agissait de tar.gz. Il est alors facile d'en extraire ou consulter un fichier texte quelconque.

4)Second essai

Après nos travaux communs d'apprentissage, mon fichier SPEC a évolué ainsi :
_ %define name bztarot _ # Pour pas écrire 10 fois le titre dans le spec, on définit une variable "name" _ # qui contient le nom du logiciel, ici c'est bztarot. _ # idem avec les variables déclarées ci-dessous : _ %define version 1.02 _ %define release 11mdk _ %define section Amusement/Cards _ %define title BzTarot _ Name: %{name} _ Summary: Jeu de tarot a 4 sous environnement graphique _ Version: %{version} _ Release: %{release} _ License: GPL _ Group: Games/Cards _ URL: http://www.beuselinck.com _ Provides: %{name} = %{version}-%{release} _ Source0: %name-%version.tar.bz2 _ Source1: %name-icons.tar.bz2 _ Packager: V.Beuselinck <vincent@beuselinck.com> _ BuildRoot: %_tmppath/%name-buildroot _ %description _ Ce jeu de tarot vous permet de jouer seul contre l'ordinateur dans des parties a 4. Respecte la reglementation de la Federation Francaise de Tarot. _ # Là, j'ai dû enlever les accents car pour rpm et urpmi ça va mais pour rpmdrake, ça n'affichait plus rien. _ %prep _ %setup -q _ %setup -q -T -D -a1 # unpack icons _ #%patch1 -p0 _ # Dans cette section, on dit à RPM de décompresser les sources. Pour la première ligne, le -a0 de la source0 est implicite. Mais pour les autres sources, il faut numéroter... _ %build _ dcc tarot.dpr _ # Dans cette section, on effectue la compilation en lançant le compilateur en ligne Kylix, à savoir dcc, sur le projet tarot.dpr _ %install _ rm -rf %buildroot _ %__install -D -m 755 tarot %buildroot/%_bindir/<HTML>%{name}</HTML> _ # un petit nettoyage de "buildroot" puis on y installe le fichier compilé dans le virtuel /usr/bin _ # Menu _ mkdir -p %buildroot/%_menudir _ cat > %buildroot/%_menudir/%name << EOF _ ?package(%name): \ _ command="%_bindir/%name" \ _ needs="X11" \ _ icon="%name.png" \ _ section="%section" \ _ title="%title" \ _ longtitle="%Summary" _ EOF _ #Ci-dessus, on crée les entrées de menu pour les menus mandrake. _ # icones et librairies _ %__install -D -m 644 %{name}48.png %buildroot/%_liconsdir/%name.png _ %__install -D -m 644 %{name}32.png %buildroot/%_iconsdir/%name.png _ %__install -D -m 644 %{name}16.png %buildroot/%_miconsdir/%name.png _ %__install -D -m 755 /usr/lib/libborqt* %buildroot/usr/lib/ _ # on installe également dans le système de fichiers virtuel les icones et librairies _ %post _ %{update_menus} _ #ça, ça marche pas, mais j'ai déjà repéré des syntaxes différentes, j'irai à la pêche pour trouver la bonne syntaxe. Le but est de demander au gestionnaire de fenêtres d'actualiser son menu puisqu'on vient d'y mettre une nouvelle entrée. Sinon, il faut attendre le prochain boot pour que ça apparaisse. _ %postun _ %{clean_menus} _ %files _ %defattr(0755,root,root,0755) _ %_bindir/* _ /usr/lib/libborqt* _ %defattr(0644,root,root,0755) _ #%doc COPYING LICENSE README INSTALL Changelog AUTHORS _ %_menudir/* _ %_miconsdir/* _ %_iconsdir/* _ %_liconsdir/* _ # Et là, on dit à RPM : tout ce que j'ai mis dans le système de fichier virtuel, tu _l'installeras au même endroit mais dans le vrai système de fichier, quand quelqu'un te demandera d'installer le RPM _ %changelog _ * Mon Nov 13 2004 Vincent Beuselinck <vincent@beuselinck.com> 1.02-11mdk _ - correctif d'une erreur en quittant le jeu _ [..]
YAHooouuuuuuuuuuuuuu ! Voilà mon RPM est fait.

Prochaines étapes : séparer les librairies, franciser dans les règles de l'art le RPM, faire que la mise à jour des menus soit immédiate, mettre le compilateur Borland dcc comme « BuildRequires », c'est-à-dire nécessaire pour compiler les sources...

Dernière partie : Accessoires et conclusion

Retour à la 3ème partie : La démarche

3- La démarche

Vincent Beuselinck — 2005-01-16T19:31:32Z

En pratique

1) Prérequis

Tout d'abord, vous devez installer quelques paquetages :
– rpm ;
– rpm-build ;
– spec-helper ;
– libtool ;
– rpmlint.

Le paquetage rpm est probablement déjà installé ;)
Pour les autres paquetages, ouvrez une console en se "loguant" en root, tapez cette commande :

urpmi rpm-build spec-helper libtool rpmlint

Il faut bien sûr accepter l'installation des dépendances que l'utilitaire urpmi vous
réclame.

Décidez maintenant quel utilisateur (ici monpseudo) va compiler le paquet : ça ne doit jamais
être root !

Passez donc sous ce login en tapant :

su monpseudo

Ensuite une deuxième commande va installer les répertoires utiles.

mkdir -p ~/rpm/{BUILD,RPMS/i586,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp}

ATTENTION : Remplacez i586 par votre architecture.
Ces répertoires sont installés dans votre répertoire personnel (/home/monpseudo selon l'exemple choisi).

2) La configuration générale

En "standard" sur Mandrake 10, vous trouverez les fichiers suivants :
~/.rpmrc : buildarchtranslate: i386: i586 buildarchtranslate: i486: i586 buildarchtranslate: i586: i586 buildarchtranslate: i686: i586 ~/.rpmmacros : %_topdir $HOME/rpm %_tmppath $HOME/rpm/tmp %_signature gpg %_gpg_name Mandrakelinux %_gpg_path ~/.gnupg %distribution Mandrakelinux %vendor Mandrakesoft
Ces deux fichiers se trouvent dans le répertoire $HOME de l'utilisateur. Comme vous le
voyez, le premier .rpmrc donne une série
d'équivalences. les développeurs de Mandriva ont pris comme plate-forme de
référence le i586.

Le second fichier contient des variables générales, à savoir :
– topdir contient le chemin vers le dossier rpm donc
/home/monpseudo/rpm.
C'est à partir de cet endroit que RPM s'attend à trouver les sous-dossiers
nécessaires à la fabrication d'un rpm (voir les prérequis).
– tmppath désigne le dossier dans lequel RPM copiera ses fichiers
temporaires pendant la fabrication de l'archive.
# Les variables ci-dessous ne sont utiles que pour le référencement Mandrake.
– signature, c'est le logiciel GPG qui servira à authentifier
votre paquet.
– gpg name, la clé de MandrakeSoft servira à signer le paquet qui sera proposé sur leur serveur [1].
– gpg path, vos fichiers de configuration gpg se trouvent là
(ici, ~/.gnupg signifie dans le dossier $HOME (le ), sous-dossier caché
gnupg.
– distribution la distribution pour laquelle votre paquet est
conçu.
– vendor c'est vous si vous ne travaillez pas pour
Mandrakesoft.

3) Les fichiers SPECs

Le fichier SPEC est un fichier texte (donc votre éditeur de texte préféré fera l'affaire) qui indique à l'application RPM comment construire votre rpm. Il se découpe en "sections". Voici des extraits commentés du squelette proposé par
Mandrakeclub que nous avons commentés :
# D'abord on définit quelques variables (name, version et release) # c'est plus simple lorsque l'on change de nom ou version de n'avoir qu'un seul endroit à changer %define name skel %define version 0.1 %define release 8mdk # Pour les Applications X, les menus Mandriva comportent une classification # (donc l'endroit de l'arborescence où poser le raccourci). %define section menu mandrake/sous-menu mandrake # la liste est sur http://qa.mandriva.com/twiki/bin/view/Main/MenuSystem_Fr %define title Skel # Le nom du logiciel avec la première lettre en capitale pour qu'il apparaisse comme ça dans les menus Mandrake # SUMMARY courte description en 60 caractères # Pas d'accents. Inutile de répéter le nom du logiciel %define Summary ma description Summary: %Summary Name: %name Version: %version Release: %release License: GPL Group: Groupe/Sousgroupe # Group définit l'arborescence de présentation dans RPMDRAKE "choix Mandrake". # La liste est sur http://qa.mandriva.com/twiki/bin/view/Main/MandrivaGroups_Fr URL: http://la.homepage.de.mon.appli.com # il est bien de rajouter également en commentaire le lien direct vers l'URL # de téléchargement Source0: %name-%version.tar.bz2 # La source 0 est généralement un tar.bz2 contenant un dossier du nom de # l'appli et la version (ici : on aura donc un dossier skel-0.1 ). Dedans, # se trouvent les fichiers sources prêts à être compilés. # La source 1 contient souvent 3 icônes nommés skel-16.png skel-32.png # skel-48.png (rappel skel = nom de mon appli) où le chiffre donne la taille # de l'icône (tar -cjf %name-icons.tar.bz2 *png permet de créer cette source) Source1: %name-icons.tar.bz2 # Vous pouvez aussi avoir des source2,3,4... Buildroot: %_tmppath/%name-buildroot # La notion de buildroot est très importante : c'est là que RPM créera un # pseudo système de fichier racine à l'intérieur duquel il pourra mettre un # pseudo /usr/bin, un pseudo /etc bref faire sembler de travailler sur / sans # risquer de mettre en danger le vrai / Buildrequires: foo-devel bar-devel Requires: foo # Utilisez ldd pour connaître les dépendances nécessaires au # logiciel (Requires) ou à sa compilation (buildrequires). # NE METTEZ PAS des dépendances implicites. Exemple: # Buildrequires: gtk+-devel XFree86-devel <- Mauvais ! # Puisque gtk+-devel a déjà besoin de XFree86-devel, vous n'avez pas besoin # d'ajouter cette seconde dépendance pour votre logiciel. # Si RPM trouve les librairies (lisez la dernière partie de la sortie console) # lui-même, vous n'avez rien à ajouter non plus. %description # Ici, vous allez mettre une description plus longue # La section "prep" (pour "preparation") commence ici : %prep %setup -q %setup -q -T -D -a1 # unpack icons #%patch1 -p0 # setup est une macro de décompression et installation des sources # c'est là que vous patcherez éventuellement vos sources au besoin %build %configure %make %install %__rm -rf %buildroot %makeinstall # Menu # Voilà la macro qui crée les entrée dans les menus Mandrake # CAT crée dans un fichier tout ce qu'il y a entre EOF et EOF # install le pose où ça va bien %__install -d %buildroot/%_menudir %__cat << EOF > %buildroot/%_menudir/%name package(%name): \ command="%_bindir/%name" \ needs="X11" \ icon="%name.png" \ section="%section" \ title="%title" \ longtitle="%Summary" EOF # icon # ici ce sont les icônes qui sont installés là où menudrake saura aller les # chercher en fonction de la taille écran. %__install -D -m 644 %{name}-48.png %buildroot/%_liconsdir/%name.png %__install -D -m 644 %{name}-32.png %buildroot/%_iconsdir/%name.png %__install -D -m 644 %{name}-16.png %buildroot/%_miconsdir/%name.png %pre %post %{update_menus} # On demande à votre environnement graphique de mettre à jour son menu pour _ # notre nouveau logiciel y apparaisse tout de suite (sans attendre un reboot) %postun %{clean_menus} # même chose en cas de désinstallation %clean %__rm -rf %buildroot # la section ci-dessous consiste à installer les fichiers à partir de buildroot # vers le véritable système de fichier donc à leur place définitive %files -f %name.lang %defattr(0755,root,root,0755) # Les fichiers désignés ci-dessous seront exécutables # tous ceux qui sont dans "bindir") donc on leur met le chmod +X (exécutable) %_bindir/* %defattr(0644,root,root,0755) # à partir d'ici ce sont les non-exécutables donc pas de chmod +X %doc COPYING LICENSE README INSTALL Changelog AUTHORS %_menudir/* %_miconsdir/* %_iconsdir/* %_liconsdir/* %_datadir/%name/* %_mandir/man1/%name.1* # Ci-dessous, on décrit ce qui change d'une version à l'autre, cela apparaitra # dans rpmdrake %changelog Sat Nov 1 2003 Han Boetes <han@linux-mandrake.com> 0.1-8mdk - more macros and other little improvements.
4) La compilation

Selon les cas, la compilation se fera de plusieurs façons.
Si vous démarrez d'un fichier src.rpm (ou "srpm"),il vous faudra taper simplement :

rpm --rebuild lenomdemonfichier.src.rpm

Et si tout va bien, vous obtendrez au final une archive lenomdemonfichier.i586.rpm (ou une autre architecture, ça dépend de votre besoin exprimé dans vos fichiers de configuration)

Si vous partez d'un tar.bz2, il vous faut taper :

rpm -ba lenomdemonfichier.spec

— C'est tout ?
— Oui, c'est tout !
— T'es sûr ?
— Bon si vous insistez, voilà d'autres possibilités...

– rpm -ba fait toute la compilation (a signifiant "all", en
français "tout") mais elle peut être décomposée en étapes :
– rpm -bp ne fait par exemple que la préparation avant
compilation
– rpm -bc va jusque la compilation mais n'installe rien dans
buildroot
– rpm -bi va jusqu'à l'installation dans buildroot mais ne
crée pas les rpm
– rpm -bb construit juste le i586.rpm mais pas le src.rpm (les
étapes précédentes sont donc faites)
– rpm -bs construit le src.rpm mais pas le i586.rpm
– rpm -bl vérifie la présence des fichiers dont il aura besoin
pour l'installation (il faut donc "construire" avant).

Dans tous les cas, on indique en paramètre le fichier spec et l'endroit où il
se trouve. Parfois celui-ci est directement dans le dossier "taré" des sources
(le sources.tar.bz2), on peut alors soit extraire ce fichier SPEC pour pouvoir
lancer notre compilation par rpm -ba soit remplacer le B de rpm -ba par un
T (rpm -ta) qui demande à rpm d'aller chercher le SPEC dans le fichier tar
des sources.

[1] La mise en oeuvre se fera par Mandrakesoft si les développeurs responsables des archives décident d'intègrer votre paquet à la distribution. Cf http://qa.mandriva.com/twiki/bin/vi...

4Úme partie : Quelques exemples

Retour à la 2Úme partie : Les principes de création d'un RPM

2- Les principes de la création d'un RPM

Vincent Beuselinck — 2005-01-16T19:29:59Z

Les principes

Pour comprendre comment construire un RPM, il est plus
simple de connaître d'abord les grandes lignes de la création d'un RPM...

RPM travaille proprement

Lorsque vous installez un logiciel à partir
de son code source, vous devez d'abord décompresser l'archive correspondante qui porte le plus souvent l'extension .tar.gz ou .tar.bz2. En effet, le code source est souvent
fourni sous la forme d'une archive compressé.
Il faut donc décompresser l'archive
dans un dossier préalablement choisi (ou bien copier l'archive dans un dossier particulier et l'y
décompresser, ce qui revient au même).
Puis, il faut préparer la compilation du programme en adaptant un fichier de configuration (Makefile) en fonction de votre architecture, des bibliothèques de fonctions présentes sur votre système, etc. Pour cela, vous utilisez la commande ./configure. Vous lancez ensuite la compilation, via un programme spécifique —make — et enfin
l'installation dans les dossiers de destination
finale [1] est effectué via la commande make install.

Or, vous avez sûrement remarqué que ces opérations ne sont pas nécessaires avec un RPM. En effet, Il n'y a pas de
manipulation préalable à l'installation d'un RPM,
ni de commandes à lancer pour terminer
celle-ci. Le fichier SPEC élaboré lors de la construction du RPM s'occupe de réaliser toutes ces opérations. Tout comme urpmi installe automatiquement un RPM en téléchargeant et installant les dépendances nécessaires, etc.
Le principe de construction d'un RPM consiste donc à configurer un fichier de manière à ce que toutes ces opérations soient effectuées. C'est en cela que RPM fonctionne proprement.

Mais ce n'est pas le seul principe de "propreté"
du RPM. Lors de la création d'un RPM, là encore, le
principe de propreté prévaut. RPM va travailler dans un dossier que vous lui aurez
désigné et il faudra y créer plusieurs
sous-dossiers dans lesquels il rangera les
fichiers par catégorie : les sources, les specs,
les binaires (par architecture), les fichiers temporaires...

Et parmi ces repertoires, le dossier "buildroot" est
là pour servir de pseudo-racine du système. En
effet, s'il est nécessaire d'agir dans d'autres
dossiers lors de l'installation [2] (avant d'obtenir le RPM final, il faut faire quelques expérimentations), il est
inacceptable que RPM puisse agir sur le système d'exploitation
Linux et ainsi le rendre instable à cause d'une
expérience au résultat surprenant (suppressions ou
modifications de fichiers par exemple). C'est la
raison pour laquelle RPM utilise le buildroot :
une fausse arborescence racine dans laquelle il
reproduira les dossiers nécessaires propres à Linux :
/usr/bin, /etc, ...

Ainsi, si la fabrication du RPM n'a pas le
résultat escompté, RPM ayant travaillé dans un
dossier séparé, votre système Linux ne sera pas
encombré par des fichiers inutiles ou dangereux.

RPM est une polka.

C'est-à-dire que l'on peut clairement distinguer
deux temps dans sa façon de construire une archive.

Tout d'abord, RPM décompresse les fichiers sources
à partir du dossier RPM/SOURCES. Attention, il
faut prévoir que ces sources soient compressés
dans un sous-dossier du nom (nom et version) de
votre logiciel pour que la décompression se fasse
dans RPM/SOURCES/logiciel_version. Par exemple, l'archive TAR de BzTarot contient un répertoire bztarot-1.02 qui contient les sources. C'est
généralement le cas avec les sources que vous irez
chercher sur le Net.

Ensuite, il va compiler le logiciel, utilisant
pour cela votre dossier temporaire. Si la
compilation se passe bien, le tout sera installé
dans RPM/BUILD. Et pour finir cette première
période, il va installer les fichiers dans le
buildroot pour simuler l'installation. Les tests,
vérifications et préparations sont terminées, le
second temps est celui de la fabrication des RPM
eux-même.

Il va créer le SRPM, un RPM particulier qui
contiendra les sources, le spec, la description,
bref tout ce qu'il faut pour quelqu'un qui
voudrait recréer le RPM. Ce paquet n'est
absolument pas exploitable, dans le sens où son
installation ne permettra pas d'utiliser le
logiciel. Enfin, il va créer le RPM qui contiendra
tous les fichiers nécessaires au fonctionnement et
à l'installation du logiciel, mais pas les
éléments qui permettraient de refaire un RPM (pas
de spec, ni source).

Certains estiment qu'il y a entre ses deux
périodes, une période intermédiaire de débogage,
correctifs, modifications, jurons et multiples
essais. C'est peut-être exact mais en scrutant aux
rayons X les RPM et SRPM, cela ne se voit pas...

[1] /usr/share/man pour les
pages man ; /usr/bin pour beaucoup de
logiciels ; /etc pour les fichiers
communs de configuration ; etc.

[2] Voir plus haut ;
et note 1.

3Úme partie : La démarche

Retour sur la 1Úre partie : Pourquoi créer ses propres paquetages

1- Pourquoi créer ses propres paquetages

Vincent Beuselinck — 2005-01-07T03:11:53Z

Avant de commencer à attaquer le vif du sujet, voici en quelques points, les raisons qui peuvent vous pousser à construire un paquetage pour votre distribution préférée.

Des raisons de créer ses RPM

Il y a plusieurs raisons pour lesquelles vous
pouvez avoir envie de faire vos RPM. Si vous
consultez cette page Web, c'est peut-être que vous
avez déjà une raison de construire votre RPM. Et
bien, vous allez en découvrir plusieurs autres.

1) Un logiciel dont vous êtes le héros (je veux dire l'auteur)

Eh oui, vous n'avez pas oublié qu'au siècle
dernier, vous étiez fier de présenter votre
application sous la forme d'un logiciel
auto-installable sous Windows construit à l'aide d'Inno Setup ou
d'InstallShield Express. Alors maintenant que vous
êtes passé au libre, présenter votre logiciel sous
la forme d'un RPM, cela va de soi !

2) Un logiciel qui n'est pas disponible pour votre plate-forme

Vous possédez un Mac ? Un AMD 64 ? un Athlon ?
Bref, une architecturee non-Intel et vous aimeriez
bien que ce logiciel trouvé sur le Net fonctionne sur votre ordinateur. Vous avez à votre disposition le paquet RPM pour architecture Intel (processeur Pentium et autre, i386, i686...) et
le paquet RPM contenant les sources du programme. La solution est de
démarrer du « SRPM » (ou src.rpm) et de compiler
le logiciel pour votre plate-forme. Vous créerez
ainsi un ppc.rpm ou un amd64.rpm !

3) Un logiciel qui n'existe qu'en archive compressée

Ha la la, cette fois c'est pire encore ! Vous
n'avez trouvé que les sources en tar.gz ou en tar.bz2 contenant les sources
? Allez-vous le compiler pour votre plateforme ?
Hé bien faites-en un RPM afin d'en faire profiter
votre entourage dans un premier temps puis, bien plus de monde encore.

4) Un RPM qui existe mais contenant un programme qui ne fonctionne pas sur votre PC

Eh oui ! Ça arrive aussi ! Erreur dans le RPM ou
bien configuration exorbitante exigée par
l'auteur du paquet...

Je vous livre ici une anecdote : J'ai installé le
RPM de BillardGL (jeu de billard comme son nom
l'indique) sur mon ordinateur familial car il
refusait de s'installer sur mon portable. Urpmi
indiquait comme dépendance un noyau supportant les
pilotes vidéo non libres nVidia accéléré avec son
module GLX. J'ai donc installé un noyau
supplémentaire adapté pour installer BillardGL.

Par erreur, j'ai lancé l'exécutable et quelle surprise !

Le lendemain, j'ai rallumé la machine en démarrant sur le
noyau original (non-nVidia) de ma distribution. Via SSH, j'ai voulu configurer en français ce jeu à partir de
mon PC portable (oui je suis un grand flemmard et
monter un étage pour modifier un fichier de
configuration était trop dur).

Par erreur, j'ai lancé l'exécutable et quelle
surprise de voir qu'il est apparu sur l'écran de
mon portable ! C'était « impossible », pour deux raisons :
– Le PC familial ne tournait pas avec
le noyau spécialement compilé pour le support des cartes nVidia, et
– le portable dispose d'une
carte graphique Intel845 de base, ne disposant pas d'accélération
graphique.

Après quelques
recherches, j'ai compris que l'auteur du paquet
RPM a imposé l'exigence d'une carte nVidia et de
son pilote "Full Patate" là où ce jeu
fonctionnerait sur bien d'autres machines
graphiquement moins performantes ! Après l'avoir
installé de force sur mon portable, j'ai recommencé la
même expérience avec un autre jeu de billard :
Foobillard. Même constat : il fonctionne
honorablement sur mon portable qui ne remplit
pourtant pas les exigences graphiques imposées par
le RPM. Donc, il est possible de construire un paquet RPM
qui n'exige pas le support des accélérations de la carte
graphique.

De quoi avoir envie de mener ses propres
expériences RPM non ?

2Úme partie : Les principes de la création d'un RPM