Forum

Bonjour,
Depuis que le dépôt est ouvert, nous espérons que certains se sentiront motivés pour proposer leur paquets.
Voici la méthode que j'utilise.
J'utilise comme outil essentiel mock qui permet de créer un espace de construction indépendant du système sur lequel il s'exécute. Historiquement l'outil de mageia est iurt, mais je ne l'ai pas testé.
J'ai créé un répertoire pack dans lequel je stocke tous mes travaux. dans ce répertoire je créé un sous répertoire par projet. Dans chaque sous répertoire de projet, je commence par créer un sous répertoire SPECS.
Le premier travail consistant à écrire un fichier .spec qui décrit la règle de construction du paquet et que je stocke dans le sous répertoire SPECS. Je ne décris pas les règles d'écriture du fichier spec ici. Une fois que le fichier spec est écrit, on commence par construire un fichier rpm de sources. Ceci se fait depuis le répertoire du projet ou depuis le répertoire SPECS. S'il n'y a qu'un seul fichier.spec, il n'est pas nécessaire de le spécifier.

Cette commande va construire un fichier paquet source .src.rpm qui sera ensuite utilisé par mock. Pour autoriser la récupération directe du fichier archive des sources, il faut une configuration spécifique qui est décrite plus loin.
Vous pouvez alors lancer la commande suivante :

Vous pouvez constater que l'option --root est suivi de la spécification de l'architecture cible. C'est là une grande force de cet outil : vous pouvez spécifier l'une quelconque des architectures gérées par Mageia. Vous pouvez également spécifier la version.
A chaque exécution mock va commencer par installer un système de base correspondant à l'architecture et à la version spécifiée. Les constructions pour arm font appel à une émulation et donc sont beaucoup plus coûteuses en termes de temps de calcul. On pourra donc utiliser par exemple :

Si on veut construire pour cauldron actuelle, on remplace mageia-8 par mageia--9.
Il faudra également configurer mock avec le fichier de configuration spécifique ~/.config/mock.cfg :

Pour d'autres options de mock, vous pouvez vous référer à la page qui est citée plus haut.

Vous récupérez ainsi les paquets construits dans le répertoire que vous avez spécifié ou dans le répertoire par défaut si vous n'avez rien spécifié comme destination. On obtient un fichier.src.rpm et le ou les paquets binaires ou noarch tel que décrits dans le fichier .spec.

Si on veut utiliser les mêmes options pour la construction locale avec rpmbuild ou bm, il faut alors créer un fichier ~/.rpmmacros avec ce contenu :


Cet article n'a pas pour ambition d'être exhaustif, loin de là, mais juste pour montrer une voie et se faire une idée générale de la méthode.

Édité par Papoteur Le 12/10/2021 à 10h41

Merci d'avoir pris le soin d'écrire ta méthode. J'imagine que ça servira à quelques apprentis et apprenties empaqueteurs

J'ai, d'ailleurs, rajouté le lien vers ce post dans la dépêche sur la réouverture du dépôt sur LinuxFr.org.

Je me demande si ça ne mériterait pas une page de wiki d'ailleurs.

Merci Ysabeau.
Oui, je me suis posé la question d'une page wiki, mais comme indiqué, c'est assez spécifiquement ma méthode actuelle. Je voulais inciter d'autres (suivez mon regard) aussi à exposer la leur, ou des variantes, de manière à aboutir à quelque chose de plus complet.

Ha ! Je ne l'avais pas compris !
Dès que j'ai le temps je me charge de "ma" méthode.

Bonjour,

Personellement, je crée une arborescence dans /home/user/rpmbuild avec les sous répertoires SOURCES,SPECS,SRPMS,RPMS,BUILD et BUILDROOT (dans RPMS, je crée les répertoires i586,x86_64,noarch ;d'ailleurs il faudrait que je rajoute les autres).

Ensuite je modifie le .rpmmacros avec un contenu similaire à celui évoqué précédement.

Ensuite je crée le fichier .specs .

Enfin je lances un "rpmbuild -ba monfichierspecs.specs" et je regardes ce qu' il se passe (bon cela ne construit que pour l' architecture de la machine sur laquelle le système tourne).

Eventuellement je fais appel au paramètre --nodebuginfo et au paramètre --target .
Il n' est pas possible d' installer mock ou autre sur ma VM, car je me bats en permanence pour trouver de l' espace disque (qui manque aussi sur la machine hôte)

Concernant l'espace disque, j'ai été aussi confronté à ce problème.
mock est configuré pour utiliser /var/lib/mock et /var/lib/cache, donc dans la partition racine par défaut. Mais il lui faut quelques Go (je pense que 3 est un strict minimum).
j'ai donc remplacé ces répertoires par des liens vers une partition qui contient plus d'espace.
La procédure normale serait de personnaliser le fichier de configuration en décommentant et personnalisant ces deux lignes (les premiers paramètres dans le fichier d'exemple dans /usr/share/doc/mock/site-defaults.cfg, à recopier dans ~/.config/mock.cfg) :

Ton hôte n'est pas une Mageia ? Avec mock, tu ne pollues pas ton installation de base, tu n'as donc pas besoin d'une machine vituelle.

Bonsoir,

J'ai pas envie de donner des ordres, mais indiquez une méthode et ne changez pas, car c'est déjà assez compliqué de faire des paquets peu importe le format mais en plus il y a toujours 50 méthodes de le faire.

Pour les RPM, je ne me prends plus la tête, j'utilise OBS et son client en ligne de commande OSC. Ce qui donne encore une énième méthode...

Perso, je prendrais la plus simple, à moins que ce soit pour former de nouveaux packagers et là effectivement il faudrait utiliser au max la méthode officiel des packagers de Mageia.

Après c'est juste un conseil mais faut bien comprendre que Mageia c'est avant tout de nouveaux utilisateurs Linuxiens ou sinon d'anciens qui ne sont pas si à l'aise avec les commandes.

Édité par seb95 Le 20/10/2023 à 12h08

Salut seb95,

Excellente réflexion. Il y a même un dilemne !
Donner une unique méthode, mais peut-être pas la plus adaptée, ou donner différentes méthodes répondant à différents cas d'utilisation…

Je me délecte de la technique, et pour "mon cas" et satisfaire ma curiosité, je suis en faveur d'avoir différentes techniques, peut-être que d'autres font mieux, plus simple que moi, je ne le saurais qu'après cet échange.

Mais le problématique que tu soulèves est bien juste… pourquoi ne pas continuer dans cette discussion exhaustive dans un premier temps, puis refaire (un énième ?) support pour l'apprentissage de l'empaquetage, reprenant la (meilleure?) méthode ici détaillée ?