RPM est le gestionnaire de paquetages Redhat (RedHat package manager). Malgr� le fait qu'il contienne RedHat dans le nom, il se veut totalement un syst�me de paquetages ouvert disponible pour tous. Il permet aux utilisateurs de prendre le code source pour des nouveaux logiciels et de l'"empaqueter" sous forme de source ou de binaire pour que les binaires puissent �tre simplement install�s et suivis et les sources recompil�es simplement. Il maintient aussi une base de don�es de tous les paquetages et de leurs fichiers qui peut �tre utilis�e pour v�rifer les paquetages et chercher des informations a propos des fichiers et/ou des paquetages.
RedHat Software encourage les autres vendeurs de distributions � prendre le temps de s'int�resser � RPM et � l'utiliser pour leur propre distribution. RPM est compl�tement flexible et simple d'utilisation, bien qu'il fournisse la base d'un syst�me tr�s puissant. Il est aussi compl�tement ouvert et disponible, bien que nous appr�ciions les rapports de bugs et les correctifs. La permission d'utiliser et distribuer RPM gratuitement est admise conform�ment � la GPL.
Une documentation plus compl�te est disponible sur RPM dans le livre d'Ed Bailey, Maximum RPM. Ce livre est disponible pour le t�l�chargement ou l'achat sur www.redhat.com http://www.redhat.com/.
Premi�rement, laissez-moi d�crire la philosophie de RPM. Un but de l'�tude �tait de permettre l'utilisation des sources "de base". Avec RPP (notre ancien syst�me de paquetages duquel rien de RPM n'est d�riv�), nos paquetages sources �taient des sources "bidouill�es" � partir desquelles nous compilions. Th�oriquement, quelqu'un peut installer un RPP source puis le compiler sans prbl�mes. Mais les sources n'�taient pas les originales, et il n'y avait pas de r�f�rence comme quels changements avsions nous fait pour que les sources compilent. Il devait t�l�charger les sources de base s�par�ment. Avec RPM, vous avez les sources de base ainsi qu'un patch que nous avons utilis� pour compiler. Nous y voyons un grand avantage. Pourquoi ? Il y a plusieurs raisons. Tout d'abord, si une nouvelle version d'un programme sort, vous ne devez pas n�cessairement repartir de rien pour obtenir la compilation par les RedHat Labs. Vous pouvez regarder le patch pour voir ce que vous avez besoin de faire. Toutes les valeurs par d�faut de compilation sont facilement visibles par ce moyen.
RPM est aussi con�u pour avoir de puissantes options de req�ete. Vous pouvez chercher � travers la base de donn�es enti�re des paquetages ou seulement certains fichiers. Vous pouvez aussi simplement trouver � quel paquetage un fichier appartient, et d'o� il vient. Les fichiers RPM eux-m�mes sont des archives compress�es, mais vous pouvez interroger des paquetages individuels simplement et rapidement gr�ce � un en-t�te binaire sp�cial ajout� au paquetage avec tout ce dont vous pouvez avoir besoin de savoir sur le contenu sous forme non-compress�e. Cela permet des requ�tes plus rapides.
Une autre fonctionnalit� puissante est la capacit� de v�rifier des paquetages. Si vous avez peur d'avoir effac� un fichier important pour un paquetage, v�rifiez-le simplement. Vous serez avertis des anomalies. A ce stade, vous pouvez r�installer le paquetage so n�cessaire. Les fichiers de configuration que vous aviez sont bien s�r pr�serv�s.
Nous aimerions remercier les gens de la distribution BOGUS pour beaucoup de leurs id�es et concepts qui sont inclus dans RPM. Quoique RPM ait �t� compl�tement �crit par RedHat Software, ses fonctions sont bas�es sur le code �crit par BOGUS (PM et PMS).
Le meilleur moyen de se procurer RPM est d'installer RedHat Linux. Si vous ne le voulez pas, vous pouvez tout de m�me obtenir et utiliser RPM. Vous pouvez vous le procurer sur ftp.redhat.com ftp://ftp.redhat.com//pub/redhat/code/rpm.
Ce qui est principalement requis pour faire tourner RPM est cpio 2.4.2 ou sup�rieur. Quoique ce syst�me soit con�u pour �tre utilis� avec Linux, il peut tr�s bien �tre port� sur d'autres syst�mes Unix. Il a, en fait, �t� compil� sur SunOS, Solaris, AIX, Irix, AmigaOS, et d'autres. Faites attention, les paquetages binaires g�n�r�s sur un syst�me Unix de type diff�rent ne seront pas compatibles.
Ce sont les exigences minimales pour installer des RPMs. Pour construire des RPMs � partir de sources, vous avez aussi besoin de ce qui est normalement requis pour compiler un paquetage, comme gcc, make, etc.
Dans sa forme la plus simple, RPM peut �tre utilis� pour installer des paquetages:
rpm -i foobar-1.0-1.i386.rpm
rpm -e foobar
rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
Bien que ce soient des commandes simples, RPM peut �tre utilis� d'une multitude de fa�ons comme le montre le message Usage:
RPM version 2.3.9
Copyright (C) 1997 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License
usage: rpm {--help}
rpm {--version}
rpm {--initdb} [--dbpath <dir>]
rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
[--replacepkgs] [--replacefiles] [--root <dir>]
[--excludedocs] [--includedocs] [--noscripts]
[--rcfile <file>] [--ignorearch] [--dbpath <dir>]
[--prefix <dir>] [--ignoreos] [--nodeps]
[--ftpproxy <host>] [--ftpport <port>]
file1.rpm ... fileN.rpm
rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
[--oldpackage] [--root <dir>] [--noscripts]
[--excludedocs] [--includedocs] [--rcfile <file>]
[--ignorearch] [--dbpath <dir>] [--prefix <dir>]
[--ftpproxy <host>] [--ftpport <port>]
[--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
[--scripts] [--root <dir>] [--rcfile <file>]
[--whatprovides] [--whatrequires] [--requires]
[--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
[--provides] [--dump] [--dbpath <dir>] [targets]
rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
[--nomd5] [targets]
rpm {--setperms} [-afpg] [target]
rpm {--setugids} [-afpg] [target]
rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--allmatches]
package1 ... packageN
rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile <file>]
[--sign] [--test] [--timecheck <s>] specfile
rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
package1 ... packageN
rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
rpm {--querytags}
Vous pouvez trouver plus de d�tails sur ce que font ces options dans la page de man de RPM.
Rpm est un utilitaire tr�s utile (!), comme vous pouvez le voir, avec de nombreuses options. Le meilleur moyen de de leur donner un sens est de regarder des exemples. J'ai abord� la simple installation/d�sinstallation plus haut, alors voici plus d'exemples :
rpm -Va
rpm -qf /usr/X11R6/bin/xjewel
xjewel-1.6-1
rpm -qpi koules-1.2-2.i386.rpm
Name : koules Distribution: Red Hat Linux Colgate
Version : 1.2 Vendor: Red Hat Software
Release : 2 Build Date: Mon Sep 02 11:59:12 1996
Install date: (none) Build Host: porky.redhat.com
Group : Games Source RPM: koules-1.2-2.src.rpm
Size : 614939
Summary : SVGAlib action game with multiplayer, network, and sound support
Description :
This arcade-style game is novel in conception and excellent in execution.
No shooting, no blood, no guts, no gore. The play is simple, but you
still must develop skill to play. This version uses SVGAlib to
run on a graphics console.
rpm -qlp koules-1.2-2.i386.rpm
/usr/doc/koules
/usr/doc/koules/ANNOUNCE
/usr/doc/koules/BUGS
/usr/doc/koules/COMPILE.OS2
/usr/doc/koules/COPYING
/usr/doc/koules/Card
/usr/doc/koules/ChangeLog
/usr/doc/koules/INSTALLATION
/usr/doc/koules/Icon.xpm
/usr/doc/koules/Icon2.xpm
/usr/doc/koules/Koules.FAQ
/usr/doc/koules/Koules.xpm
/usr/doc/koules/README
/usr/doc/koules/TODO
/usr/games/koules
/usr/games/koules.svga
/usr/games/koules.tcl
/usr/man/man6/koules.svga.6
Ce sont juste quelques exemples. De plus cr�atifs peuvent �tre proches de ce que vous pouvez vraiment faire en �tant familier de RPM.
Compiler ses RPMs est tr�s simple, sp�cialement si vous pouvez obtenir du logiciel que vous essayez qu'il se compile tout seul.
La proc�dure de base pour compiler un RPM est la suivante :
En utilisation normale, RPM construit aussi bien des paquetages sources que des binaires.
Maintenant, la seule configuration de RPM is disponible via le fichier /etc/rpmrc. Un exemple de celui-ci ressemble � :
require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <packages@mickiesoft.com>
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp
tmppath: /usr/tmp
La ligne require_vendor fait que RPM trouve une ligne vendor. Elle peut provenir du fichier /etc/rpmrc ou de l'en-t�te du fichier spec lui-m�me. Pour d�sactiver ceci, mettez le nombre � 0. Cela reste vrai pour les lignes require_distribution et require_group.
La ligne suivante est la ligne distribution. Pour pouvez d�finir cela ici ou plus tard, dans l'en-t�te du fichier spec. Quand vous compilez pour une distribution particuli�re, il est conseill� de s'assurer que cette ligne est correcte, bien que �a ne soit pas requis. La ligne vendor fonctionne selon le m�me principe, mais peut �tre n'importe quoi (ex: Joe's Software and Rock Music Emporium).
RPM supporte aussi maintenant la cr�ation de paquetages sur des architectures multiples. Le fichier rpmrc peut conserver une variable "optflags" pour compiler ce qui requiert des options sp�cifiques � l'architecture durant la compilation. Voir plus loin les paragraphes concernant l'utilisation de cette option.
En suppl�ment des macros ci-dessus, il y en a beaucoup plus. Vous pouvez utiliser :
rpm --showrc
Nous avons commenc� � parler du fichier spec. Les fichiers spec sont requis pour construire un paquetage. Le fichier spec est une description du logiciel accompagn�e des instructions concernant sa compilation, ainsi qu'une liste des fichiers pour tous les binaires qui seront install�s.
Il est recommand� nommer votre fichier spec conform�ment � une convention standard, c'est � dire nom_du_paquetage-num�ro_de_version-num�ro de release.spec.
Voici un petit fichier spec (vim-3.0-1.spec):
Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.
%prep
%setup
%patch -p1
%patch1 -p1
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1
%files
%doc README COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1
L'en-t�te comporte des champs standard que vous devez remplir. Il y a quelques restrictions bien s�r. Les champs doivent �tre remplis comme suit :
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
Ces fichiers iront dans le r�pertoire SOURCES (la structure des r�pertoires est abord�e dans un autre paragraphe, "L'arborescence du r�pertoire des sources".)
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
Applications
Communications
Editeurs
Emacs
Ing�ni�rie
Tableurs
Bases de donn�es
Graphiques
R�seau
Mail
News
Publication
TeX
Base
Noyau
Utilitaires
Archive
Console
Fichiers
Syst�me
Terminal
Texte
D�mons
Documentation
X11
XFree86
Serveurs
Applications
Graphiques
R�seau
Jeux
Strat�gie
Vid�o
Amusements
Utilitaires
Librairies
Gestionnaires de fen�tres
Librairies
R�seaux
Admin
D�mons
News
Utilitaires
D�veloppement
D�buggeurs
Librairies
Libc
Langages
Fortran
Tcl
Construction
Contr�le de version
Utilitaires
Shells
Jeux
C'est la seconde section du fichier spec. Il est utilis� pour pr�parer les sources � la compilation. Vous mettez ce que vous avez besoin de faire pour patcher les sources et param�trer, comme ce que vous mettriez pour compiler les sources.
Une chose importante: chacune de ces sections est simplement un emplacement pour ex�cuter des scripts shell. Vous pourriez simplement faire un script sh et le mettre apr�s le tag %prep pour d�compresser et patcher vos sources. Nous avons con�u des macros pour aider � cela, toutefois.
La premi�re de ces macros est %setup. Dans sa forme la plus simple (pas d'options de ligne de commande), elle d�compresse simplement les sources et se rend dans le r�pertoire des sources. Elle prend aussi les options suivantes :
La macro suivante est la macro %patch. Cette macro aide � automatiser le processus d'application des patches aux sources. Il comporte plusieurs options, list�es ici :
Ce sont toutes les macros dont vous avez besoin. Apr�s que vous les ayez faites, vous pouvez �galement faire un autre r�glage dont vous avez besoin via un script sh. Tout ce que vous incluez jusqu'� de la macro %build (�voqu�e dans la section suivante) est ex�cut� par sh. Regardez l'exemple plus haut afin de vous donner une id�e du genre de choses que vous pouvez faire ici.
Ils n'y a pas de vraies macros pour cette section. Vous devez juste mettre ici les commandes dont vous avez besoin pour compiler le logiciel lorsque vous avez d�tarr� les sources, patch�es celles-ci, et vous �tre rendu dans le r�pertoire. C'est juste un autre ensemble de commandes pass�es � sh, donc n'importe quelle commande accept�e par sh peut �tre plac�e ici (y compris des commentaires). Votre r�pertoire de travail courant est r�tabli dans ces sections au r�pertoire racine des cources, gardez cela en m�moire. Vous devez changer de r�pertoire pour atteindre les sous-r�pertoires si n�cessaire.
De m�me, il n'y a pas ici non plus de vraies macros. Vous mettrez ici simplement les commandes donc vous avez besoin pour installer. Si vous avez un "make install" disponible dans le paquetage que vous compilez, mettez-le ici. Sinon, vous pouvez patcher le Makefile pour un "make install" et faire juste un make install ici, ou l'installer � la main ici avec des commandes sh. Consid�rez que votre r�pertoire courant est le r�pertoire racine de vos sources.
Vous pouvez mettre des scripts qui seront ex�cut�s avant et apr�s l'installation et la d�sinstallation de paquetages binaires. Une des principales raison pour �a est la n�cessit� de lancer /sbin/ldconfig apr�s l'installation ou la suppression de paquetages contenant des librairies partag�es. Les macros pour chacun de ces scripts sont les suivantes:
Le contenu de ces sections doit ressembler � un script sh, sauf que vous n'avez pas besoin de #!/bin/sh.
C'est la section o� vous devez lister les fichiers pour le paquetage binaire. RPM n'a aucun moyen de connaitre quels fichiers sont install�s par le "make install". Il n'y a PAS de moyen de le savoir. Certains ont sugg�r� de faire un "find" avant et apr�s l'installation. Avec un syst�me multiutilisateur, c'est inacceptable car d'autres fichiers qui n'ont rien � voir peuvent �tre cr�es pendant le processus d'installation.
Il y a plusieurs macros disponibles pour faire des choses sp�ciales. Elles sont list�es et d�crites ici:
nomfichier va vous permettre de lister vos fichiers dans un fichier arbitraire � l'int�rieur du r�pertoire de compilation des sources. C'est pratique dans le cas o� vous avez un paquetage qui ne peut pas construire sa propre liste de fichiers. Vous incluez alors simplement cette liste de fichiers ici, et vous ne devez pas lister les fichiers sp�cifiquement.Le plus gros inconv�nient dans le liste de fichier est la liste des r�pertoire. Si vous listez /usr/bin par accident, votre paquetage va contenir tous les fichiers de /usr/bin sur votre syst�me.
La premi�re chose dont vous avez besoin est une arborescence de compilation bien configur�e. C'est configurable dans /etc/rpmrc. La plupart des gens utiliseront simplement /usr/src.
Vous aurez probablement besoin de cr�er les r�pertoires suivants pour construire l'arborescence de compilation:
La premire� chose que vous voudrez probablement faire est de compiler proprement la source sans utiliser RPM. Pour faire cela, d�compressez les sources, et changez le nom du r�pertoire en $NAME.orig. Ensuite re-d�compressez les sources. Utilisez ces sources pour compiler. Allez � l'int�rieur de celui-ci et suivez les instructions de compilation pour le compiler. Si vous devez �diter des choses, vous aurez besoin d'un patch. D�s que vous r�uississez � le compiler, nettoyez le r�pertoire des sources. Effacez les fichiers qui ont �t� obtenus par le script configure. Ensuite, remontez au r�pertoire parent. Vous ferez ensuite quelque chose comme :
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
Cela cr�era un patch pour vous que vous pourrez utilisez dans votre fichier spec. Notez que le "linux" que vous voyez dans le nom du patch est juste un identificateur. Vous voudrez s�rement utiliser quelque chose de plus descriptif comme "config" ou "bugs" pour d�crire pourquoi vous avez d� faire un patch. De plus il est recommand� de v�rifier dans le fichier patch que vous avez cr�� que vous n'avez pas inclus de binaires par accident avant de l'utiliser.
Maintenant que vous avez des souces qui vont compiler et que vous savez comment le faire, compilez-les et installez-les. Regardez la sortie de la s�quence d'installation et construisez la liste de fichiers que vous utiliserez dans le fichier spec � partir de celle-ci. On construit habituellement le fichier spec en parall�le avec toutes ces �tapes. Vous pouvez cr�er celui de base et remplir ses parties les plus simples, et ensuite remplir les autre �tapes au fur et � mesure.
D�s que vous avez un fichier spec, vous �tes pr�t � essayer et � compiler votre paquetage. Le voie la plus utilis�e pour faire cela est avec une commande qui ressemble � la suivante :
rpm -ba foobar-1.0.spec
Il y a plusieurs modificateurs � l'option -b. Ce sont les suivants:
D�s que vous avez des rpms source et binaire pour votre paquetage, vous devez le tester. La voie la plus simple et la meilleure est d'utiliser pour les tests une machine totalement diff�rente de celle sur laquelle vous avez construit le paquetage. Apr�s tout, vous avec juste fait un ensemble de "make install" sur votre propre machine, alors il pourrait aussi bien �tre install�.
Vous pouvez faire un rpm -u nom_du_paquetage sur le paquetage pour tester, mais vous pouvez �tre d��u parce durant la construction du paquetage, vous avez fait un make install. Si vous avez laiss� quelque chose en dehors de votre liste des fichiers, il ne sera pas d�sinstall�. Vous r�installerez alors le paquetage binaire et votre syst�me sera de nouveau complet, mais votre rpm toujours pas. Gardez � l'esprit que vous faites un rpm -ba paquetage, la plupart des peersonnes installeront simplement celui-ci avec rpm -i paquetage. Assurez-vous de ne rien faire dans la section build ou install qui aura besoin d'�tre fait quand les binaires seront install�s par eux-m�mes.
D�s que vous avez construit votre propre rpm de quelque chose (si il n'a pas d�j� �t� "RPMis�"), vous pouvez faire profier les autres de votre travail (si votre rpm est un logiciel librement redistribuable). Pour cela, vous l'uploaderez sur ftp://contrib.redhat.com/
Regardez les sections pr�c�dentes Tests et Que faire ... Nous voulons tous les RPMs que nous pouvons obtenir, et nous voulons que ce soient tous les bons RPMs. Prenez le temps de les tester correctement, et ensuite prenez le temps de les uploader afin que chacun en b�n�ficie. De m�me, assurez-vous que vous uploadez uniquement des logiciels librement redistribuables. Les logiciels commerciaux et les sharewares ne doivent pas �tre upload�s � moins que le copyright le permette explicitement. Cela inclut Netscape, ssh, pgp, etc.
RPM peut maintenant �tre utilis� pour construire des paquetages pour intel 386, le Digital Alpha faisant tourner linux, et le Sparc. Il a �t� signal� qu'il fonctionnait aussi bien sur des stations de travail SGI et HP. De nombreuses options permettent de construire des paquetages sur toutes les plateformes facilement. La premi�re de celles-ci est la directive "optflags" dans /etc/rpmrc. Elle peut �tre utilis�e pour positionner des options utilis�s durant la compilation concernant des valeurs sp�cifiques � l'architecture. Elles peuvent �tre utilis�es pour faire diff�rentes choses qui d�pend de l'architecture sur laquelle vous compilez. Une fonctionnalit� est la directive "Exclude" dans le header.
La partie qui suit est extraite du fichier spec pour le paquetage fileutils. Il est param�tr� pour compiler aussi bien sur Alpha que sur Intel.
Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch
%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.
The ls program in this package now incorporates color ls!
%prep
%setup
%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s
%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*
Dans cet exemple, vous pouvez voir comment la directive "optflags" est utilis�e dans le /etc/rpmrc. Selon l'architecture sur laquelle vous compilez, la valeur est donn�e � RPM_OPT_FLAGS. Vous devez patcher le Makefile pour votre paquetage pour utiliser cette variable � la place des directives normales que vous utilisez probablement (comme -m486 et -O2). Vous pouvez obtenir un meilleur aspect de ce dont vous avez � faire par l'installation du paquetage source, la d�compression de celui-ci et l'examen du Makefile. Ensuite regardez au patch pour le Makefile et voyez les changements � faire.
la macro %ifarch est tr�s important pour tout cela. LA plupart du temps vous autre besoin de faire un patch ou deux qui sera sp�cifique � une architecture seulement. Dans ce cas, RPM va vous permettre d'appliquer ce patch uniquement sur cette architecture.
Dans l'exemple plus haut, fileutils a un patch pour les machines 64 bits. Manifestement, cela doit uniquement �tre appliqu� sur Alpha � ce jour. Donc, on ajoute une macro %ifarch pour le patch 64 bits comme suit:
%ifarch axp
%patch1 -p1
%endif
Comme vous pouvez maintenir les RPMs sources dans un r�pertoire pour toutes les plateformes, nous avons impl�ment� la capacit� d'exclure des paquetages d'�tre compil�es sur certaines architectures. C'est ce que vous pouvez faire avec quelque chose comme
rpm --rebuild /usr/src/SRPMS/*.rpm
et vous obtenez les vrais paquetages compil�s. Si vous n'avez pas encore port� une application sur une certaine platefome, tout ce que vous devez faire est une ligne comme:
ExcludeArch: axp
� l'en-t�te du fichier spec des paquetages source. Ensuite recompilez les paquetages sur les plateformes sur lesquelles il compile. Vous aurez alors un paquetage source qui compile sur Intel et peut facilement �tre saut� sur Alpha.
Utilisez RPM pour construire des paquetages multi-architectures est habituellement plus simple � faire que d'obtenir du paquetage lui-m�me qu'il compile sur des architectures diff�rentes. Aussi plus les paquetages compilent difficilement plus vous obtiendrez de facilit� (Ndt: ?). Comme toujours, la meilleure aide quand la construction d'un RPM vous pose probl�me est de regarder un paquetage source similaire.
Ce document et son contenu sont prot�g�s. La redistribution de ce document est permise tant que le contenu demeure compl�tement intact et inchang�. En d'autres mots, vous pouvez changer le format et le r�imprimer ou redistribuer seulement.