This page has been marked as "old", and likely contains content that is irrelevant or incorrect. If you can, please update this page. This page will be deleted if action is not taken.
Sommaire de la documentation:
Objectif : Expliquer comment construire et modifier les paquets.
Public : Les utilisateurs expérimentés intéressés par la création de paquets RPM, pour le projet de Fedora ou pour leur propre utilisation.
Hypothèses : Le lecteur dispose de l'accès "root" à un système Fedora.
Documents liés : maximum rpm
Auteur principal : IgnacioVazquezAbrams
Note de RahulSundaram à l'auteur :
Il semble y avoir un guide disponible relatif à cela. Vous pourriez vouloir composer avec le travail déjà fait.
http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html (en)
Note de VilleSkyttä :
le manuel de l'empaqueteur est sur le CVS, rubrique documentation, cf [1] (en)
Construire des Paquets sous Fedora
Changelog (en)
2005.08.22: 0.0 : Initial proposal (Ignacio Vazquez-Abrams)
2005.08.30: 0.1 : Moved to wiki (Ignacio Vazquez-Abrams)
2005.09.10: 0.2 : Filled in intro to "Creating a New Package" and "Case Study: leafpad" (Ignacio Vazquez-Abrams)
2005.10.31: 0.3 : Filled in mock appendix (Ignacio Vazquez-Abrams)
2005.12.30: 0.4 : Adjusted the creating a non-root rpmbuild Buildroot (James Lawrence)
2006.03.16: 0.5 : Filled in the library section (Ignacio Vazquez-Abrams)
Introduction
RPM, le gestionnaire de logiciels, est au cœur de Fedora. Il permet l'installation de nouveaux logiciels, aussi bien que le suivi des fichiers installés, de sorte que le même logiciel puisse être désinstallé le plus proprement possible. Mais RPM, en lui même, ne fait absolument rien. C'est l'empaqueteur qui doit préciser comment le paquet est construit, et expliquer quels types de fichiers le paquet contient et de quels autres paquets il dépend.
Objectif
Ce guide explique comment construire des paquets sous Fedora, procédure différente de celle des autres distribution Linux utilisant les paquets RPM. Il n'est pas destiné à être un guide approfondi des fichiers *.spec et des options de rpmbuild. Pour avoir ces informations, vous êtes invités à lire la dernière version de Maximum RPM .
Public
Ce guide est écrit pour ceux qui veulent concevoir des paquets pour Fedora.
Structure d'un Paquet
- En-tête
Contient des informations telles que le nom, la version, la révision, la date de la compilation, l'architecture pour laquelle le paquet a été construit, ainsi que les dépendances du paquet et les fichiers qu'il fournit à d'autres.
- Les fichiers
Contient tous les fichiers, répertoires, liens symboliques, etc. contenus dans le paquet, la taille, les permissions, les propriétaires, et ses propriétés liées à SELinux.
- Script
Contient le script qui sera lancé durant l'installation et désinstallation du paquet, ainsi qu'un script lancé durant la vérification d'un RPM.
Créer un Nouveau Paquet
Les sources compressées du programme sont pratiques. Elles peuvent contenir presque tout et peuvent être ouvertes sur n'importe quel système d'exploitation. Le problème est que les fichiers installés depuis ces sources compressées sont presque impossibles à repérer. C'est pourquoi il est utile de transformer ces sources en un paquet. Dans cette partie,nous étudierons plusieurs exemples.
Créer un répertoire de construction
La plupart des codes source des logiciels sont fournis sous forme de tarballs (une archive .tar compressée avec gzip ou bzip2). Il est possible que, par erreur, le code contenu dans un makefile ou un script, puisse endommager votre système. Pour cette raison, il vaut mieux construire les paquets en tant qu'utilisateur ayant une accès limité au système.
Il est facile de créer un répertoire de construction détaché du système principal:
- En tant que "super-utilisateur" (root), installez le paquet rpmdevtools depuis fedora-extras,
yum install rpmdevtools
- En tant qu'utilisateur lambda, lancez
rpmdev-setuptree
Cela crée un répertoire ~/rpmbuild où les paquets seront construits, puis ajoute des options essentielles au fichier ~/.rpmmacros - Ouvrez le fichier ~/.rpmmacros dans un éditeur de texte, et ajoutez-y ces quelques options à la fin du fichier :
%packager Votre nom <Votre adresse mail>Cela permet à d'autres de vous contacter si des personnes veulent vous poser des questions concernant votre paquet.%vendor votre pseudo/surnomfournit une manière facile de distinguer vos paquets des paquets du même logiciel fait à partir d'autres sources.
Étude de cas: leafpad
Leafpad est une application très simple. Pour l'installation, il requiert seulement le binaire, l'icône, l'entrée de menu, et les traductions (via gettext). Cela fait de lui un bon exemple pour une étude de l'empaquetage. La page principale de leafpad, est à l'adresse : [2] (en).
La première étape est de se rendre dans le répertoire de construction et de créer un fichier SPEC pour votre paquet. dans un terminal, lancez les commandes suivantes :
cd ~/rpmbuild/SPECS rpmbuild -bc leafpad.spec
Cela crée un nouveau fichier SPEC générique, nommé leafpad.spec. Ouvrez-le dans un éditeur de texte.
Name: leafpad
Version:
Release: 1
Summary:
Group:
License:
URL:
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires:
Requires:
%description
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
Puisque c'est un paquet officieux, la première chose à faire est de donner à 'Release' une valeur inférieure à 1. En outre, placer une "étiquette" dans la révision permet ensuite d'identifier la provenance du paquet.
Ensuite, vous remplissez les champs version (0.8.3 à l'heure où nous écrivons), et summarry (résumé), à partir de données trouvées sur le site web.
Version: 0.8.3 Release: 0.docs.1 Summary: A GTK+ based simple text editor
Maintenant, nous devons classer le paquet dans un groupe approprié. Les groupes sont listés dans /usr/share/doc/rpm-*/GROUPS ou dans les groupes RPM (en). Ici, le groupe approprié est Applications/Editors puisque leafpad est un éditeur de texte.
Pour le champs licence, Leafpad est diffusé sous la GPL. Depuis le site de leafpad, récupérez l'url de téléchargement de leafpad 0.8.3. Utilisez toutes ces informations pour compléter la prochaine section :
Group: Applications/Editors License: GPL URL: http://tarot.freeshell.org/leafpad/ Source0: http://savannah.nongnu.org/download/leafpad/leafpad-0.8.3.tar.gz
Ensuite, vous devez vous familiariser avec buildrequires et requires. Selon la page Web de leafpad, le logiciel a besoin de GTK+ >= 2.0.0 afin d'être compilé ou lancé. Vous pouvez laisser RPM vous indiquer les bibliothèques dont il a besoin pour se lancer. Ainsi complétez le BuildRequires et commentez le champ requires pour l'instant comme ceci.
BuildRequires: gtk2-devel >= 2.0.0 #Requires:
Ajoutez une description pour le paquet: les lignes du texte dans %description ne doivent pas être plus longues que 79 caractères.
%description Leafpad is a GTK+ based simple text editor. The user interface is similar to Notepad. It aims to be lighter than GEdit and KWrite, and to be as useful as them.
Pour l'instant, nous sauterons la majeure partie des sections et nous allons seulement nous pencher sur %changelog pour le moment. Complétez-le avec la date (La commande LC_TIME=en_US date +"%a %b %e %Y" vous donnera exactement le texte que vous devriez mettre), votre nom, votre adresse mail, la version et révision du paquet et une brève description des changements apportés par cette nouvelle version. Comme c'est le premier paquet, nous allons juste mettre :
%changelog * Gud Fez 74 6395 Foobly Barowitz <foobly@barowitz.tld> 0.8.3-0.docs.1 - Initial RPM release
Maintenant, le fichier SPEC devrait ressembler à cela (avec la date d'aujourd'hui, votre nom et votre adresse mail dans la section %changelog qui sera donc différente).
Name: leafpad
Version: 0.8.3
Release: 0.docs.1
Summary: A GTK+ based simple text editor
Group: Applications/Editors
License: GPL
URL: http://tarot.freeshell.org/leafpad/
Source0: http://savannah.nongnu.org/download/leafpad/leafpad-0.8.3.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: gtk2-devel >= 2.0.0
#Requires:
%description
Leafpad is a GTK+ based simple text editor. The user interface is similar to
Notepad. It aims to be lighter than GEdit and KWrite, and to be as useful as
them.
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc
%changelog
* Gud Fez 74 6395 Foobly Barowitz <foobly@barowitz.tld> 0.8.3-0.docs.1
- Initial RPM release
Maintenant, il faut télécharger la source de Leafpad et la placer dans le répertoire approprié. Continuez en téléchargeant le tarball (source compressée) avec votre navigateur, wget, curl, ou tout autre utilitaire. Ensuite, déplacez-le dans ~/rpmbuild/SOURCES.
Maintenant que vous avez votre fichiers SPEC et les fichiers source, il faut passer à la conception du paquet, ce qui nécessite de d'aller à la fin à la fin du champ %build : Entrez les commandes suivantes dans un terminal :
cd ~/rpmbuild/SPECS rpmbuild -bc leafpad.spec
A ce stade, vous finirez très probablement par avoir un message d'erreur, particulièrement si vous n'avez jamais construit de paquet sur votre machine auparavant. Regardons-les de plus près un à un.
- bash: /usr/bin/rpmbuild: No such file or directory
Celui-ci indique que vous avez besoin d'installer le paquet rpm-build cependant, vous devriez déjà l'avoir installé puisque c'est une dépendance de rpmdevtools que vous avez dû installer afin de créer précédemment l'arborescence de construction non-root.
- error: Failed build dependencies:
gtk2-devel >= 2.0.0 is needed by leafpad-0.8.3-0.docs.1.i386
Ce message vous indique que vous avez besoin au préalable d'installer des fichiers ou paquets avant de pouvoir construire le paquet en question. Vous pouvez utiliser YUM pour installer les fichiers ou paquets requis. Dans ce cas présent, vous utiliserez yum install gtk2-devel pour installer les fichiers manquants.
Une fois que le paquet sera construit correctement, la dernière ligne de la sotie sera + exit 0. Vous pouvez continuer et tester %install comme ceci :
rpmbuild -bi leafpad.spec
A ce stade, vous verrez certainement des erreurs :
RPM build errors: Installed (but unpackaged) file(s) found: /usr/bin/leafpad /usr/share/applications/leafpad.desktop /usr/share/locale/bg/LC_MESSAGES/leafpad.mo /usr/share/locale/ca/LC_MESSAGES/leafpad.mo /usr/share/locale/cs/LC_MESSAGES/leafpad.mo /usr/share/locale/de/LC_MESSAGES/leafpad.mo /usr/share/locale/es/LC_MESSAGES/leafpad.mo /usr/share/locale/fr/LC_MESSAGES/leafpad.mo /usr/share/locale/hu/LC_MESSAGES/leafpad.mo /usr/share/locale/it/LC_MESSAGES/leafpad.mo /usr/share/locale/ja/LC_MESSAGES/leafpad.mo /usr/share/locale/lt/LC_MESSAGES/leafpad.mo /usr/share/locale/pl/LC_MESSAGES/leafpad.mo /usr/share/locale/pt/LC_MESSAGES/leafpad.mo /usr/share/locale/ru/LC_MESSAGES/leafpad.mo /usr/share/locale/sk/LC_MESSAGES/leafpad.mo /usr/share/locale/sv/LC_MESSAGES/leafpad.mo /usr/share/locale/ta/LC_MESSAGES/leafpad.mo /usr/share/locale/vi/LC_MESSAGES/leafpad.mo /usr/share/locale/zh_CN/LC_MESSAGES/leafpad.mo /usr/share/locale/zh_TW/LC_MESSAGES/leafpad.mo /usr/share/pixmaps/leafpad.png
Le prochaine étape est de prendre tous ces fichiers et de les mettre dans %files. Par contre juste les copier/coller seraient la mauvaise chose à faire.
RPM a de nombreuse macros qui peuvent être utilisées pour raccourcir le fichier SPEC ou le rendre plus flexible. Vous pouvez voir certaines de ces macros à la page MacrosRPM .
Vous pouvez obtenir une liste complète de ces macros en lançant rpm --showrc.
Continuez donc en ajoutant tous les fichiers (sauf ceux sous /usr/share/locale/) à %files, substituant les chemins par des macros lorsque nécessaire.
%files
%defattr(-,root,root,-)
%doc
%{_bindir}/leafpad
%{_datadir}/applications/leafpad.desktop
%{_datadir}/pixmaps/leafpad.png
Maintenant, vous avez besoin de manipuler les fichiers sous /usr/share/local. Heureusement, Fedora fournit la macro %find_lang pour cela. Il cherche tous les fichiers sous /usr/share/local qui correspondent avec les arguments que vous lui avez passés et les mets dans un fichier du même nom apposé avec un ".lang". La macro est appelé à la fin de %install. Puisque le nom du paquet est "leafpad", nous pouvons employer la macro appropriée à la place.
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%find_lang %{name}
Et vous devez également préciser à %files d'inclure tous les fichiers listé dans le fichier généré.
%files -f %{name}.lang
%defattr(-,root,root,-)
%doc
%{_bindir}/leafpad
%{_datadir}/applications/leafpad.desktop
%{_datadir}/pixmaps/leafpad.png
A ce stade, le paquet sera construit mais, il y a une autre étape à accomplir avant d'être prêt. Vous avez besoin de compléter le champ %doc, dans %files, avec toutes les documentations de l'application. Allez dans ~/rpmbuild/BUILD/leafpad-0.8.3, et regardez les fichiers qui y sont. La majorité d'entre eux ne sont nécessaire qu'à la construction de l'application mais il est utile d'en inclure certain. Les fichiers spécifiques qui vous intéressent, sont AUTHORS, ChangeLog, COPYING, NEWS et README alors, allez-y et ajoutez-les à %doc dans %files.
%files -f %{name}.lang
%defattr(-,root,root,-)
%doc AUTHORS ChangeLog COPYING NEWS README
%{_bindir}/leafpad
%{_datadir}/applications/leafpad.desktop
%{_datadir}/pixmaps/leafpad.png
Maintenant, vous pouvez continuer et tester le paquet à nouveau.
rpmbuild -bi leafpad.spec
Ça marche! Vous pouvez y aller et construire les paquets binaire et source.
rpmbuild -ba leafpad.spec
Vers la fin du processus, vous verrez trois fichiers créés. Le premier, est le paquet source (*.src.rpm), le seconde est le paquet binaire (*.rpm) et le troisième est l'information de déboguage pour le paquet binaire. Si vous avez déjà leafpad d'installé depuis Fedora Extras, allez-y et supprimez-le maintenant et installez le nouveau paquet binaire en tant que root.
rpm -e leafpad rpm -Uvh /path/to/leafpad-0.8.3-0.docs.1.$(uname -i).rpm
Après l'avoir installé, une entrée dans le menu accessoires devrait apparaître. Allez-y, lancez-le et essayez-le un petit peu.
Vous pouvez remarquer que leafpad utilise actuellement l'ancien style du fichier GTK+ de la boite de dialogue pour ouvrir et sauvegarder les fichiers. Afin de le faire utiliser le nouveau style du fichier GTK+ de la boite de dialogue, vous devriez normalement lancer ./configure --help pour voir les différentes options, mais la production d'un paquet approprié corrompt les fichiers nécessaires. Dans un terminal lancez les commandes suivantes :
cd ~/rpmbuild/SPECS rpmbuild -bp leafpad.spec
Cela passe juste par la section %prep du fichier SPEC (décompresse la source et applique tous les patches). Maintenant vous pouvez réaliser ce qui suit pour voir les options :
cd ~/rpmbuild/BUILD/leafpad-0.8.3 ./configure --help
Dans le cas où l'option que vous cherchez est --enable-chooser. Allez-y et modifiez %build comme il faut.
%build
%configure --enable-chooser
make %{?_smp_mflags}
Maintenant, vous avez besoin d'incrémenter la révision et d'ajouter une entrée à %changelog.
Version: 0.8.3 Release: 0.docs.2 Summary: A GTK+ based simple text editor
%changelog * Gud Fez 74 6395 Foobly Barowitz <foobly@barowitz.tld> 0.8.3-0.docs.2 - Enabled new-style GTK+ file dialog * Gud Fez 74 6395 Foobly Barowitz <foobly@barowitz.tld> 0.8.3-0.docs.1 - Initial RPM release
Alors, reconstruisez le paquet.
rpmbuild -ba leafpad.spec
Puisque la révision du nouveau paquet est supérieure à ce dernier, vous pouvez le mettre à jour directement en tant que root.
rpm -Uvh /path/to/leafpad-0.8.3-0.docs.2.$(uname -i).rpm
Lorsque vous le lancerez, vous verrez que le chargement et la sauvegarde de fichiers utilise maintenant le nouveau style de la boite de dialogue pour les fichiers.
Étude de cas: OpenEXR
OpenEXR} est une bibliothèque créée par [http://www.ilm.com/ Industrial Light & Magic (en) pour créer et utiliser des images dynamiques de grande qualité. Créez et complétez le fichier SPEC pour OpenEXR de la même manière que vous l'avez fait pour leafpad.
Name: OpenEXR
Version: 1.2.2
Release: 0.docs.1
Summary: A high dynamic-range (HDR) image file format
Group: System Environment/Libraries
License: BSD
URL: http://www.openexr.com/
Source0: http://savannah.nongnu.org/download/openexr/OpenEXR-1.2.2.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires:
#Requires:
%description
OpenEXR is a high dynamic-range (HDR) image file format developed by
Industrial Light & Magic for use in computer imaging applications.
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc
%changelog
* Gud Fez 74 6395 Foobly Barowitz <foobly@barowitz.tld> 1.2.2-0.docs.1
- Initial RPM release
Malheureusement, la page web d'OpenEXR donne peu d'informations sur les paquets requis pour construire la bibliothèque. Commentez la ligne Buildrequires pour l'instant. Téléchargez la source et lancez l'étape %prep :
#BuildRequires: #Requires:
rpmbuild -bp OpenEXR.spec
Allez dans le répertoire BUILD/OpenEXR-1.2.2 et ouvrez le fichier INSTALL. Dans la plupart des paquets, on y trouve les instructions de construction. Parfois, il y a même une liste des dépendances. Malheureusement, ce n'est pas le cas d'OpenEXR. Alors fermez ce fichier et ouvrez README à la place. A propos de Halfway, on lit dans le fichier: "exrdisplay require FLTK 1.1 or greater". Revenez alors au fichier spec et ajoutez-le à BuildRequires en oubliant pas de décommenter la ligne.
BuildRequires: fltk-devel >= 1.1 #Requires:
Maintenant, essayez de compiler le paquet.
rpmbuild -bc OpenEXR.spec
error: Failed build dependencies: fltk-devel >= 1.1 is needed by OpenEXR-1.2.2-0.docs.1.i386
Bien sûr, vous devez maintenant installer le paquet fltk-devel afin de construire OpenEXR alors, faite le maintenant avec YUM. Une fois que cela est fait, essayez de compiler le paquet à nouveau.
checking for strerror... yes checking for compress in -lz... no configure: error: *** OpenEXR requires a recent version of zlib, which you don't appear to *** have. *** *** This could be because the run-time linker is not finding zlib, or it *** is finding the wrong version. In this case, you'll need to set your *** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point *** to the proper version. Also, make sure you have run ldconfig if *** that is required on your system. error: Bad exit status from /var/tmp/rpm-tmp.XXXXX (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.XXXXX (%build)
Il semble que FLTK ne soit pas le seul paquet exigé pour la construction de OpenEXR. Allez-y et ajouter zlib-devel à BuildRequires et installer le via YUM.
BuildRequires: fltk-devel >= 1.1 zlib-devel #Requires:
Compiler une fois de plus
[more messages above] makeTiled.cpp: In function 'void<unnamed>::reduceY(const TypedImageChannel<T>&, TypedImageChannel<T>&, bool, Extrapolation, bool) [with T = unsigned int] ': makeTiled.cpp:447: instantiated from here makeTiled.cpp:318: error: 'class TypedImageChannel<unsigned int>' has no member named 'image' makeTiled.cpp:319: error: 'const class TypedImageChannel<unsigned int>' has no member named 'image' makeTiled.cpp:320: error: 'class TypedImageChannel<unsigned int>' has no member named 'image' make[1] : *** [makeTiled.o] Error 1 make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.XXXXX (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.XXXXX (%build)
N'est-ce pas une situation intéressante que celle-ci ? Ce qui s'est produit ici, c'est que le compilateur a détecté un problème dans la source et a échoué parce que le compilateur ne peut pas le comprendre. Si vous faites défiler les messages vers le haut jusqu'aux premier messages d'erreur, vous pouvez obtenir un indice au sujet de ce qui cause l'erreur.
./Image.h:59: error: expected <code>)' before '&' token ./Image.h:64: error: ISO C++ forbids declaration of 'Image' with no type ./Image.h:64: error: expected ';' before '&' token
Dans ce cas là, la seconde ligne indique que la source utilise un datatype avant qu'il ne sache que le datatype existe. Sur cette ligne, nous voyons que le problème est dans un fichier appelé image.h. Faites défiler les messages vers le haut, pour découvrir où ce fichier est localisé.
Making all in exrmaketiled make[1] : Entering directory <code>~/rpmbuild/BUILD/OpenEXR-1.2.2/exrmaketiled'
Allez à ce répertoire, ouvrez image.h et allez à la ligne 59.
#!cplusplus start=53 numbers=on
class ImageChannel
{
public:
friend class Image;
ImageChannel (Image &Image);
virtual ~ImageChannel();
virtual Imf::Slice slice () const = 0;
Image & image () {return _image;}
const Image & image () const {return _image;}
Ce que vous avez ici est le commencement de la déclaration pour la classe ImageChannel.Quand vous examinez les problèmes dans les messages d'erreur énumérés ci-dessus par rapport au code source, vous notez qu'ils se réfèrent tous à Image.La norme de C++ impose de ne pas employer un type avant que le compilateur en sache suffisamment à son sujet. Ainsi, la déclaration Friend à la ligne 57 n'est pas suffisante. Vous devez ajouter une ligne indiquant au compilateur la classe Image. Mais avant de faire cette modification, copiez le fichier sous le nom Image.h.friend :
cp Image.h Image.h.friend
Mettez maintenant une déclaration de la classe Image avant la déclaration de la classe ImageChannel
#!cplusplus start=49 numbers=on
class Image;
class ImageChannel
{
Puisque RPM utilise les sources d'origine pour construire le paquet, vous devez maintenant concevoir un patch contenant la différence entre le fichier original et celui modifié. RPM fournit un outil commode pour cela appelé gendiff. Une fois lancé contre un répertoire et qu'il soit passé, il comparera tous les fichiers avec ce suffixe aux fichiers correspondant sans ce dernier et générera un patch avec les changements :
cd ~/rpmbuild/BUILD gendiff OpenEXR-1.2.2 .friend > ../SOURCES/OpenEXR-1.2.2-friend.patch
Le patch généré devrait ressembler à ceci:
--- OpenEXR-1.2.2/exrmaketiled/Image.h.friend YYYY-MM-DD hh:mm:ss.xxxxxxxxx -ZZZZ
+++ OpenEXR-1.2.2/exrmaketiled/Image.h YYYY-MM-DD hh:mm:ss.xxxxxxxxx -ZZZZ
@@ -49,6 +49,7 @@
+class Image;
class ImageChannel
{
Ajoutez maintenant le patch au fichier SPEC afin que Rpmbuild l'utilise durant la construction.
Source0: http://savannah.nongnu.org/download/openexr/OpenEXR-1.2.2.tar.gz
Patch0: OpenEXR-1.2.2-friend.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%prep %setup -q %patch0 -p1 -b .friend %build
Compilez le paquet une fois de plus.
make[1] : Leaving directory <code>/home/ignacio/work/rpmbuild/BUILD/OpenEXR-1.2.2/exrenvmap' make[1] : Entering directory <code>/home/ignacio/work/rpmbuild/BUILD/OpenEXR-1.2.2' make[1] : Nothing to be done for <code>all-am'. make[1] : Leaving directory <code>/home/ignacio/work/rpmbuild/BUILD/OpenEXR-1.2.2' + exit 0
C'est beaucoup mieux là. initialisez maintenant la phase d'installation :
rpmbuild -bi OpenEXR.spec
RPM build errors: Installed (but unpackaged) file(s) found: /usr/bin/exrdisplay /usr/bin/exrenvmap /usr/bin/exrheader /usr/bin/exrmakepreview /usr/bin/exrmaketiled /usr/bin/exrstdattr /usr/include/OpenEXR/Iex.h /usr/include/OpenEXR/IexBaseExc.h ... /usr/include/OpenEXR/halfFunction.h /usr/include/OpenEXR/halfLimits.h /usr/lib/libHalf.a /usr/lib/libHalf.la /usr/lib/libHalf.so /usr/lib/libHalf.so.2 /usr/lib/libHalf.so.2.0.2 /usr/lib/libIex.a /usr/lib/libIex.la /usr/lib/libIex.so /usr/lib/libIex.so.2 /usr/lib/libIex.so.2.0.2 /usr/lib/libIlmImf.a /usr/lib/libIlmImf.la /usr/lib/libIlmImf.so /usr/lib/libIlmImf.so.2 /usr/lib/libIlmImf.so.2.0.2 /usr/lib/libImath.a /usr/lib/libImath.la /usr/lib/libImath.so /usr/lib/libImath.so.2 /usr/lib/libImath.so.2.0.2 /usr/lib/pkgconfig/OpenEXR.pc /usr/share/aclocal/openexr.m4 /usr/share/doc/OpenEXR-1.2.2/examples/drawImage.cpp /usr/share/doc/OpenEXR-1.2.2/examples/drawImage.h ... /usr/share/doc/OpenEXR-1.2.2/examples/rgbaInterfaceTiledExamples.cpp /usr/share/doc/OpenEXR-1.2.2/examples/rgbaInterfaceTiledExamples.h
C'est un grand nombre de fichiers. Heureusement vous n'avez pas besoin de spécifier chaque fichiers l'un après l'autre. L'indication d'un répertoire inclura chaque fichier du répertoire. Mais avant de lès ajouter, remarquez que beaucoup de ces fichiers sont des bibliothèques et des en-tête C/C++. Vous devrez créer un sous-paquet devel pour y contenir les fichiers exigés pour la construction de OpenEXR.
%description
OpenEXR is a high dynamic-range (HDR) image file format developed by
Industrial Light & Magic for use in computer imaging applications.
%package devel
Summary: Headers and libraries for building apps that use OpenEXR
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
%description devel
This package contains headers and libraries required to build applications that
use the OpenEXR format.
%prep
%files %defattr(-,root,root,-) %doc %files devel %defattr(-,root,root,-) %doc %changelog
La tarball place également des exemples dans le répertoire de documentation du paquet principal, alors qu'ils serait plus logique de les placer dans le sous-paquet devel.
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
rm -rf $RPM_BUILD_ROOT%{_defaultdocdir}/%{name}-%{version}/examples
Tous les fichiers exécutables et *.so devront être placé dans le paquet principal.
%files
%doc
%{_bindir}/*
%{_libdir}/*.so.*
Tous les en-tête, bibliothèques statiques, archives libtool, fichiers *.so*, autotools et les fichiers pkgconfig vont dans le sous-paquet -devel.
%files devel
%defattr(-,root,root,-)
%doc
%{_includedir}/%{name}
%{_libdir}/*.a
%{_libdir}/*.la
%{_libdir}/*.so
%{_libdir}/pkgconfig/%{name}.pc
%{_datadir}/aclocal/*.m4
Nous devrions ajouter les exemples à la documentation dans le sous-paquet -devel. Normalement nous voudrions utiliser :
%doc examples
pour cela. Mais, malheureusement il y a deux problèmes. Le premier c'est que le répertoire n'est pas nommé "examples". En regardant les divers fichiers sous BUILD/OpenEXR-1.2.2, nous constatons que le répertoire s'appelle réellement "I'lmImfExamples". Le second problème est que le répertoire contiendra plusieurs fichiers que nous voulons pas inclure dans le paquet final. Ce qui devrait être fait, c'est de le copier dans %prep avec le nom approprié et supprimer les fichiers indésirés. Par la suite ajouter ces fichiers à %docs dans le sous-paquet -devel et tous les paquets approprié dans le %docs du paquet principal.
%prep %setup -q %patch0 -p1 -b .friend cp -a IlmImfExamples examples rm examples/Makefile*
%files
%defattr(-,root,root,-)
%doc AUTHORS ChangeLog LICENSE NEWS README
%{_bindir}/*
%{_libdir}/*.so.*
%files devel
%defattr(-,root,root,-)
%doc examples
%{_includedir}/%{name}
%{_libdir}/*.a
%{_libdir}/*.la
%{_libdir}/*.so
%{_libdir}/pkgconfig/%{name}.pc
%{_datadir}/aclocal/*.m4
Puisque le paquet place ses bibliothèques partagés dans un répertoire normal, /sbin/ldconfig devra être invoqué après que le paquet ait été installé ou désinstallé comme décrit dans Scriptletsnippets.
%clean rm -rf $RPM_BUILD_ROOT %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %files
Donc si vous le reconstruisez maintenant, vous verrez que la procédure se déroule correctement. Allez-y, lancez la construction et installez par la suite le paquet binaire.
rpmbuild -bb OpenEXR.spec rpm -Uvh /path/to/OpenEXR-1.2.2-0.docs.1.arch.rpm /path/to/OpenEXR-devel-1.2.2-0.docs.1.arch.rpm
Modifier un paquet existant
(A FAIRE : consultez les diverses raisons pour lesquelles on voudrait modifier un paquet existant).
Étude de cas: KDElibs
(A FAIRE : modifier le paquet KDElibs pour y ajouter le support OpenEXR)
Étude de cas: PHP
(A FAIRE : modifier le paquet PHP pour y ajouter le support MS SQL via FREE TDS)
Annexe : Mock : Chroot Buildtool
Note de BobJensen à l'auteur : Projects/Mock est la page de mock sur le wiki.
Transformer un fichier SPEC, une source et un patch en un paquet final est un processus plutôt complexe. Les paquets de développement installés peuvent altérer le paquet avec des effets inattendus. Ce qui amènera les utilisateur du paquet à se plaindre lorsqu'il manque certaines fonctionnalités à leurs constructions. En plus, il est très facile d'oublier BuildRequires qui doit être ajouter au fichier SPEC.
les systèmes d'exploitation de type Unix fournissent un outil connu sous le nom de chroot qui transforme un sous-répertoire en un répertoire racine temporairement. Mock utilise cet outil pour fournir un environnement propre à la construction d'un paquet. Seul un petit nombre de paquets de base, et les paquets énumérés dans BuildRequires, sont installés dans le répertoire chroot, et Mock construit ensuite le paquet sous ce répertoire. Cela permet une construction propre et reproductible du paquet.
Mock accepte les options suivantes :
- -r <root> : Cela donne le répertoire racine que vous souhaitez utiliser. Il devrait fonctionner avec l'un des fichiers de configuration qui se trouve dans /etc/mock.
- --resultdir=<directory> : Ceci indique à Mock où vous voulez que les logs et les paquets conçus soient placés.
- <source package> : C'est la source RPM que vous voulez construire.
Exemple: mock -r fedora-4-i386-core --resultdir=mock-leafpad-0.8.3 leafpad-0.8.3-0.docs.2.src.rpm
Le fichier de configuration est actuellement un script Python qui crée un dictionnaire (config_opts) qui contient toutes les valeurs utilisé par Mock pour générer le chroot et établir les paquets source. Les clefs dans le dictionnaire incluent :
- root : Le répertoire sous /var/lib/mock dans lequel génère le chroot.
- target_arch : L'architecture que chroot contiendra.
- yum.conf : Le contenu du fichier de configuration de yum utilisé par le chroot.
- macros : Un ensemble de macros RPM à initialiser par mock.
Annexe: Plague: Buildsystem distribué
(A faire : la description de ce que veut dire "distribué", ainsi que des capacités de plague en ce qui concerne la compilation croisée)
(A FAIRE : la description de la configuration de plague-builder et -server)
(A FAIRE : la description de l'utilisation de plague-client)