Easybashgui 10.0.0
Introduction
Cet article inaugure une petite chronique dont l'idée m'est venue pendant l'exécution de tâches répétitives (ie: mon travail IRL). J'ai en effet réalisé que le Web foisonne d'éléments pour la construction initiale de paquets RPM, d'ordre théorique (wikis, documentations...) et d'ordre pratique (articles de blog, paquets du dépôt Fedora...). Sauf que, un paquet RPM est voué à évoluer depuis sa création, les modifications provenants du programme empaqueté ou du paquet lui-même pour correspondre aux évolutions de la distribution Linux. On n'envoie pas un paquet dans le dépôt puis on l'oublie.
Prérequis
Avoir le groupe de paquets Fedora Packager installé sur votre machine :
# yum install @rpm-development-tools
Récupération des sources du paquet
Chaque paquet du dépôt Fedora possède un petit dépôt à code source dans lequel le propriètaire du paquet peut travailler. Ce petit dépôt est visible en ligne ici pour Easybashgui, il contient les fichiers nécessaires à la construction du RPM, c'est à dire le fichier SPEC, et l'archive à code source du programme empaqueté. Il est basé sur le système de contrôle de version GIT. On ne dit pas « télécharger » un dépôt mais « cloner », nous allons donc cloner le dépôt du paquet Easybashgui sur notre disque dur :
casper@blackbird:~/fedora-scm$ fedpkg clone -a easybashgui
L'option -a signifie « anonyme » car les accès aux dépôts sont contrôlés par les comptes FAS. La première chose à vérifier est que le paquet embarque bien la dernière version du logiciel :
casper@blackbird:~/fedora-scm/easybashgui$ egrep 'URL|Version' easybashgui.spec
Version: 8.0.1
URL: https://sites.google.com/site/easybashgui/
Allons-voir sur le site à l'url indiquée. Sur la page Download on voit que la version actuelle du logiciel est 10.0.0, il est temps de mettre à jour le paquet.
Récupération des sources du logiciel
Comme nous venons de voir, les sources du logiciel sont hébergées sur la plateforme d'hébergement Github, qui offre un système de téléchargement de l'archive assez spécial. En fait Github dispose lui-aussi d'un système de contrôle de version, avec la possiblité d'associer un commit à un tag. Ici le commit (court) est "ad4222f", et le tag est défini arbitrairement par le développeur qui indique ici la version de son logiciel. Il nous manque encore une information avant de pouvoir commencer : la version longue de l'identifiant du commit, que l'on obtient en cliquant sur l'identiant court : "ad4222f0082adc877a35c0f3984b2cc7c8319d9b". Après cette petite navigation dans Github, nous disposons de toutes les information requises pour modifier le SPEC.
casper@blackbird:~/fedora-scm/easybashgui$ head -1 easybashgui.spec
%global commit f39fd3b22e7af267613d35de659b94c3f55b9fb1
On peut remplacer l'ancien commit qui indiquait la version 8.0.1 par le nouveau :
casper@blackbird:~/fedora-scm/easybashgui$ sed -i s/f39fd3b22e7af267613d35de659b94c3f55b9fb1/ad4222f0082adc877a35c0f3984b2cc7c8319d9b/ easybashgui.spec
Puis on met à jour le tag Version :
casper@blackbird:~/fedora-scm/easybashgui$ sed -i 's/Version: 8.0.1/Version: 10.0.0/' easybashgui.spec
Et enfin on ajoute une entrée au %changelog :
--- easybashgui.spec.orig 2014-01-20 01:18:32.637223701 +0100
+++ easybashgui.spec 2014-01-20 01:19:52.216888031 +0100
@@ -78,6 +78,9 @@ chmod 644 easybashgui_test.sh
%changelog
+* Mon Jan 20 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 10.0.0-1
+- Update to 10.0.0
+
* Tue Aug 06 2013 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 8.0.1-1
- Update to 8.0.1
- Upstream has moved sources on github
Avec ces modifications, nous pouvons désormais télécharger l'archive à la version du logiciel souhaitée avec l'outil spectool :
casper@blackbird:~/fedora-scm/easybashgui$ spectool -g -S easybashgui.spec
Puis on commence le travail d'investigation pour savoir ce qui a changé dans le logiciel qu'il faut adapter dans le RPM. J'ai pour habitude de copier l'archive dans le répertoire ~/Téléchargements/ pour l'extraire et pouvoir fouiller en profondeur dedans.
L'évolution du logiciel
Jusqu'à la version 8.0.1, je n'utilisais pas le Makefile fourni car il était partiellement erroné (au niveau des modes des fichiers), aujourd'hui il apparait que tout est OK pour les modes, nous allons donc désormais l'utiliser. Dans la partie %install du SPEC, il va falloir tout remplacer par la commande make install.
On voit aussi que le développeur a trié ses fichiers sources dans les répertoires icons/ lib/ et scr/, ce qui n'était pas le cas dans la version précédente. Du coup, la commande sed dans la partie %prep du SPEC ne va plus fonctionner. Sauf que, en cherchant dans l'archive, le fichier easybashgui_test.sh n'est plus là, en conséquence nous allons supprimer la commande sed qui n'a plus lieu d'exister.
Du coté des fichiers qui vont être installés par le RPM, le nom de certains fichiers installés a changé. Par exemple l'ancien easydialog.sh se nomme désormais easydialog. L'emplacement des deux fichiers de bibliothèque a également changé. Tous ces changements seront répercutés sur la section %files du SPEC.
Et enfin, malgrès le développement intensif de cette bibliothèque, les dépendances indispensables à son fonctionnement (tag Requires dans le SPEC) semblent inchangés.
Les modifications du RPM
On ouvre son éditeur de texte préféré et on modifie le fichier SPEC dans l'ordre précédemment énoncé :
La partie %install
--- easybashgui.spec.orig 2014-01-20 01:56:56.976175885 +0100
+++ easybashgui.spec 2014-01-20 23:46:11.130181100 +0100
@@ -44,27 +44,7 @@ sed -i "s@#!/usr/bin/env bash@@" easybashgui_test.sh
%install
-# Install binaries :
-mkdir -p %{buildroot}%{_bindir}/
-install -pm 755 %{name} \
- %{name}-debug \
- easydialog.sh \
- %{buildroot}%{_bindir}/
-# Install lib files :
-mkdir -p %{buildroot}%{_libexecdir}/%{name}/
-install -pm 755 %{name}.lib \
- easybashlib \
- %{buildroot}%{_libexecdir}/%{name}/
-# Install shared files :
-mkdir -p %{buildroot}%{_datadir}/%{name}/
-install -pm 644 Ok.xpm \
- Attenzione.xpm \
- %{buildroot}%{_datadir}/%{name}/
-# Install man file
-mkdir -p %{buildroot}%{_mandir}/man1/
-install -pm 644 %{name}.1* %{buildroot}%{_mandir}/man1/
-# Fix mode of easybashgui_test.sh :
-chmod 644 easybashgui_test.sh
+make install DESTDIR=%{buildroot}
%files
La partie %prep
--- easybashgui.spec.orig 2014-01-20 23:49:16.987846224 +0100
+++ easybashgui.spec 2014-01-20 23:54:40.296437416 +0100
@@ -35,8 +35,6 @@ lancé ou non.
%prep
%setup -qn %{name}-%{commit}
-# Remove shebang from easybashgui_test.sh :
-sed -i "s@#!/usr/bin/env bash@@" easybashgui_test.sh
%build
La partie %files
Cette partie mérite quelques explications avant de balancer le diff. En effet, si on lit le Makefile, on aperçoit que les fichiers de documentation (README, EasyBashGUI-license) sont installés par la commande make install. Rien d'extraordinaire en soi, sauf que dans cette partie existe déjà une macro sensée copier automatiquement ces fichiers doc dans le répertoire /usr/share/doc/ et d'assigner la propriété de ces fichiers au paquet. La copie des fichiers avec la macro %doc fait doublon avec le Makefile. Toutefois, il faut que ces fichiers soient assignés au paquet. Pour cela nous allons simplement ajouter le répertoire des fichiers doc à la liste des fichiers dont le paquet est propriétaire, et enlever la macro %doc.
Pour la conversion des macros en chemins, il y a une page de page de doc très utile qui liste tout ici (juste au cas où).
--- easybashgui.spec.orig 2014-01-21 00:55:31.425925488 +0100
+++ easybashgui.spec 2014-01-21 01:00:31.694894978 +0100
@@ -46,13 +46,13 @@ make install DESTDIR=%{buildroot}
%files
-%doc README EasyBashGUI-license easybashgui_test.sh
%{_bindir}/%{name}
%{_bindir}/%{name}-debug
-%{_bindir}/easydialog.sh
+%{_bindir}/easydialog
%{_datadir}/%{name}/
-%{_libexecdir}/%{name}/
+%{_prefix}/lib/%{name}/
%{_mandir}/man1/%{name}.1*
+%{_docdir}/%{name}/
%changelog
La partie %changelog
Toutes nos modifications doivent être consignées dans le ChangeLog du paquet. Alors pas la peine d'écrire un roman, mais il faut être bref et précis. Voici un exemple :
--- easybashgui.spec.orig 2014-01-21 01:10:16.772114046 +0100
+++ easybashgui.spec 2014-01-21 01:16:30.220338188 +0100
@@ -58,6 +58,10 @@ make install DESTDIR=%{buildroot}
%changelog
* Mon Jan 20 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 10.0.0-1
- Update to 10.0.0
+- Use makefile instead of scriplet in %%install section
+- Remove sed statement in %%prep section
+- Remove %%doc macro in %%files section
+- Update %%files section according the makefile
* Tue Aug 06 2013 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 8.0.1-1
- Update to 8.0.1
Vous aurez remarqué que dans le ChangeLog, j'ai ajouté un caractère % avant chaque nom de section (qui commence elle-même par %). C'est juste pour que ces macros ne soit pas interprétées au moment de la construction du paquet. Alors ça y est, nous allons enfin pouvoir le construire ce paquet. Mais avant...
Enregistrement des modifications
N'oublions pas que nous sommes dans notre petit dépôt GIT et que toutes les modifications que nous venons de faire n'ont pas encore d'identifiant. Mais avant, il faut encore ajouter l'archive au fichier « sources » (c'est comme ça qu'il s'appelle). L'archive sera également mise en ligne en une seule passe :
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg new-sources easybashgui-10.0.0-ad4222f.tar.gz
Et enfin on enregistre les changements, en ajoutant un message expliquant sommairement nos modifications :
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg commit -m "Update to 10.0.0 version"
Cet enregistrement n'est présent que sur notre disque dur pour l'instant, il faut donc synchroniser notre dépôt local avec le dépôt distant. Pour cela on dit qu'on « pousse » les modifications, d'où la commande suivante :
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg push
Construction du paquet pour Rawhide
Maintenant que nos modifications sont mises en ligne, nous pouvons construire le paquet contenant la dernière version du logiciel, mais seulement pour la branche Rawhide. Tout ce que nous venons de faire était dans la branche master du dépôt GIT, cette branche est la première branche à être modifiée, et elle correspond à la branche en évolution permanante de Fedora, c'est à dire Rawhide.
Si tout se passe bien dans cette branche, alors on pourra répliquer les changement dans les branches plus anciennes telles que f20 puis f19.
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg build --nowait
Building easybashgui-10.0.0-1.fc21 for rawhide
Created task: 6432471
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6432471
Si le build a réussi, alors cette version du paquet sera présente automatiquement dans les futures versions de Fedora, c'est à dire f21, f22, etc...
Faire une update pour f20
Si les changements du logiciel n'influancent pas de façon majeure l'expérience utilisateur et développeur d'une version de Fedora, alors nous pouvons produire une mise à jour pour la version courante de Fedora. À l'heure de la rédaction de cet article, les versions 20 et 19 sont les versions courantes de Fedora.
Commençons par changer de branche dans notre dépôt local :
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg switch-branch f20
Puis on applique les modifications faites dans la branche master aux fichiers de la branche f20. Dans notre cas de figure, et heureusement pour nous, tout cela est fait automatiquement avec une seule commande :
casper@blackbird:~/fedora-scm/easybashgui$ git merge master
On n'oublie pas de synchroniser cette branche avec la branche du dépôt distant :
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg push
Et on peut enfin construire notre paquet. Cette branche n'étant pas une branche de test, les échecs de constructions sont plutôt rares. Pour ma part, les échecs de construction étaient dûs à chaque fois à de petites erreurs d'inattention...
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg build --nowait
Building easybashgui-10.0.0-1.fc20 for f20-candidate
Created task: 6436984
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6436984
Une fois construit, ce paquet sera tagué en tant que paquet candidat pour une mise à jour. Ce qui signifie qu'il ne sera pas poussé automatiquement dans les dépôts (updates-testing et updates) avant que je puisse le vérifier. Ensuite, il faut remplir un petit descriptif qui permettra aux utilisateurs de connaître la nature de cette mise à jour (sécurité, avancement, etc..) et les bugs qu'il corrige. C'est ce formulaire assigné au paquet qui permet aux testeurs de lui donner une évaluation et un commentaire. C'est également cette étiquette qui permet de suivre la progression du paquet dans les différents dépôts (d'abord updates-testing, puis updates).
casper@blackbird:~/fedora-scm/easybashgui$ fedpkg update
Creating a new update for easybashgui-10.0.0-1.fc20
Password for fantom:
Creating a new update for easybashgui-10.0.0-1.fc20
Update successfully created
================================================================================
easybashgui-10.0.0-1.fc20
================================================================================
Release: Fedora 20
Status: pending
Type: enhancement
Karma: 0
Request: testing
Notes: Update to 10.0.0
Submitter: fantom
Submitted: 2014-01-21 23:09:01
Comments: bodhi - 2014-01-21 23:09:04 (karma 0)
This update has been submitted for testing by fantom.
https://admin.fedoraproject.org/updates/easybashgui-10.0.0-1.fc20
Après cette opération, le paquet est tagué en tant que paquet de mise à jour en attente. En attente, car avant d'intègrer le dépôt updates-testing, il y a délai un pour laisser le temps à la personne en charge de la clé de signature GPG du Projet Fedora de faire la signature sur ce paquet. C'est une opération manuelle qui prend 24/48h en général. D'ici 7 jours, si le paquet ne reçoit aucune évaluation négative, je pourrais le pousser dans le dépôt updates.
La politique des Mises à Jour est indiquée dans le règlement des mises à jour de Fedora.
Et pour f19 ?
Renouveler l'opération en adaptant :-D