chkconfig Portable off

Sommaire ● Introduction ✔ RPM : Définition ✔ Pourquoi utiliser RPM ? ● Création de paquetages ✔ Pré-requis ✔ Ça commence ! ✔ Les Macros ✔ Le fichier SPEC En-tête Requires & BuildRequires %prep, %build, %install %files %changelog ✔ Construction du paquetage : étapes ✔ rpmlint : qualité ✔ mock : contrôle et qualité ● Mise à disposition – Participer au Projet Fedora ● Inscription ● Demande de revue ● Soumission du paquet ● Et ensuite ?

Présentation

Système de gestion de paquets logiciels À l'origine : RedHat Package Manager Acronyme de : RPM Package Manager RPM : Définition

● Pour l'administrateur – installation – gestion des dépendances – Suivi des mises à jour ● Pour l'utilisateur – pas de compilation – configuration minimum Pourquoi utiliser RPM ?

● Pour la sécurité – paquets signés numériquement – Paquets binaires ● Pour le packageur – facilité de mise à jour – facilité de distribution Pourquoi utiliser RPM ?

Création de paquetages

● RPM binaire : un RPM destiné à être installé sur un système particulier (distribution, architecture, version) ● RPM Source : RPM contenant le nécessaire à la reconstruction du ou des RPM binaires ● Fichier SPEC : fichier décrivant les opérations nécessaire à la construction des RPM binaires (il est inclus dans le SRPM) Définitions

● Création d'un utilisateur spécifique ● Installation des outils de développement génériques (gcc, g++, sed, make, patch,...) : le groupe « Development Tools » ● Installation des outils de développement RPM : rpmbuild, rpmdevtools,... Pré-requis

Depuis le compte « builder » : ➢ rpmdev-setuptree ➢ cd ~/rpmbuild/SPECS ➢ rpmdev-newspec nom_du_fichier Ensuite, amusez-vous ! Ça commence !

Le fichier SPEC

● Automatiser certaines tâches ● Éviter les erreurs ● Standardiser les options de compilation ● /usr/lib/rpm/macros ● /usr/lib/rpm/i386-linux/macros ● /etc/rpm/* ● %{name} ● %{version} ● %{_sysconfdir} ● %{_libdir} ● %{_bindir} ● %{_datadir} ● %{_localstatedir} ● %find_lang Les Macros

Name: nom_du_spec Version: Release: 1%{?dist} Summary: Group: License: URL: Source0: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root- %(%{__id_u} -n) BuildRequires Requires %description En-tête BuildRoot : peut-être : %(mktemp -ud %{_tmppath}/%{name}- %{version}-%{release}-XXXXXX)

Name: ksplash-engine-moodin Version: Release: 3%{?dist} Summary: KDE ksplash Moodin engine Group: User Interface/Desktops License: GPL URL: Source0: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root- %(%{__id_u} -n) BuildRequires Requires %description En-tête - Moodin BuildRoot : peut-être : %(mktemp -ud %{_tmppath}/%{name}- %{version}-%{release}-XXXXXX)

Requires : Paquetages dont dépend le paquet courant, pour son bon fonctionnement (kdebase pour un logiciel KDE, kernel pour un module noyau,...) Remarque : beaucoup de dépendances sont auto-détectées par rpmbuild. BuildRequires (BR) Paquetages dont dépend le paquet courant pour être correctement compilé (kdebase-devel pour un logiciel KDE, kernel-devel pour un module noyau,...) Requires & BuildRequires

%prep %setup -q Compilation - %build %build %configure make %{?_smp_mflags} Installation - %install %configure make %{?_smp_mflags} make install DESTDIR=$RPM_BUILD_ROOT Préparation - %prep Optionnel - %check Test de non régression. Exemple : make test

%files %defattr(-,root,root,-) %doc À retenir : %{_libdir} -> bibliothèques (/usr/lib | /usr/lib64) %{_bindir} -> exécutables (/usr/bin) %{_sysconfdir} -> fichiers de configuration (/etc) %{_datadir} -> /usr/share %{_localstatedir} --> /var %find_lang et %files -f %{name}.lang %exclude %config -> identifie un fichier comme fichier de configuration, permet de gérer le traitement des sauvegardes (.rpmsave et.rpmnew) Fichiers - %files

%post Cette section contient tout ce qui doit être fait après l'installation du paquetage %preun Cette section contient tout ce qui doit être fait avant la désinstallation du paquetage %postun %pre Cette section contient tout ce qui doit être fait avant l'installation du paquetage Cette section contient tout ce qui doit être fait après la désinstallation du paquetage

Installation %pre de la version 1 (avec $1 = 1) => copie des fichiers %post de la version 2 (avec $1 = 1)

Mise à jour %pre de la version 2 (avec $1 = 2) => copie des fichiers %post de la version 2 (avec $1 = 2) %preun de la version 1 (avec $1 = 1) => nettoyage des fichiers (si besoin) %postun de la version 1 (avec $1 = 1)

Désinstallation %preun de la version 1 (avec $1 = 0) => nettoyage des fichiers %postun de la version 1 (avec $1 = 0)

%changelog * Sat Jun Johan Cwiklinski Since new version is now available in many languages, we must use the find_lang macro * Thu Jun Christophe Polyte Updated to new version * Wed Jun Remi Collet We must use macros everywhere * Mon Jun Johan Cwiklinski Some files should not be excluded * Fri Jun Johan Cwiklinski Initial RPM creation %changelog

Utiliser la macro %find_lang dans la section %install Passer le fichier en argument à %files : %files -f %{name}.lang En cas de problèmes avec %find_lang, utiliser %lang Les fichiers de langues

Construction & Vérifications

Réglage des patches, des BR,... (%prep) rpmbuild -bp Compilation (%build) rpmbuild -bc --short-circuit Empaquetage, contrôle des fichiers (%install et %files) rpmbuild -bi --short-circuit Contrôle des fichiers (%files) rpmbuild -bl --short-circuit Construction - Étapes

Les RPM binaires (%prep, %build, %install...) rpmbuild -bb Le RPM des sources (aucune compilation) rpmbuild -bs Les RPM binaires et le RPM des sources rpmbuild -ba Construction des paquets

rpmlint est fourni par le paquet éponyme ● vérification des droits des fichiers ● vérification des emplacements d'installation ● pas de fichiers de développement dans les paquets binaires Vérification - rpmlint

Construction de votre paquet dans un environnement dédié et sécurisé ● Installation de zéro : vérification des BuildRequires ● Environnement chrooté : pas de risque pour le système installé ● Possibilité de construire des paquets pour des versions antérieures Vérification - mock

Participer au Projet Fedora (distribution des paquetages)

● Ouverture d'un compte Wiki ● Signature du contrat de licence (CLA) ● Inscription au système de compte Fedora (clés GPG et SSH requises) ● Inscription sur le Bugzilla de RedHat ● Inscription aux listes de diffusion de développement Inscription

● Ouverture d'une entrée sur le Bugzilla pour le nouveau paquet ● Corrections éventuelles en fonction des commentaires laissés ● Attente d'approbation du paquet ● Demande de sponsoring (pour le premier paquetage notamment) Demande de revue Bugzilla est fabuleux ;-)

Une fois votre paquet approuvé : ● Demande de la création des dossiers sur le CVS (version n, n-1 et devel) ● Transmission des fichiers vers le CVS Soumission du paquetage

Une fois le paquet sur le serveur CVS : ● Requête auprès du serveur de « build » pour chaque version Fedora ● Vérification du build => Le nouveau paquetage sera disponible, après signature, sur les dépôts officiels Publication

● Maintenance du paquet ● Traitement des bogues déclarés par les utilisateurs ● Travail avec le projet (upstream) ● Mise à jour des nouvelles versions ou intégration des correctifs Et ensuite ?

Questions / Réponses

Nous ne pouvons pas attendre pour vous impressionner L'équipe Merci de votre attention !