Cuisine de paquet .deb et dependances

Support Debian
#1

[quote=“fran.b”][quote=“youki”]
Par contre en suivant le tuto sur fabriquer des paquets, j’ai bien compris comment utiliser checkinstall par exemple, mais j’ai pas reussi a indiquer les dependances a mes paquets (par exemple).[/quote]
C’est l’utilisation du script lsdepend avec comme exemple scilab-4??[/quote]

Oui, c’est ca. Je vais detailler dans le post qui suit ce que j’ai fais de A a Z que tout soit le plus clair possible. Voir si ca peut aider a eclaircir le tuto pour moi ou d’autres aussi.

#2

Bon, pour commencer il me faut un paquet a compiler, dont je n’ai pas forcement besoin, mais qui pour l’exemple soit simple a compiler et qui ne soit pas dans les depots. Je choisis gmencoder.

Je decompresse les sources :

Je change le nom du repertoire (j’ai plusieurs systemes sur le meme ordi, et je range mes .deb au meme endroit, ca me permet de les differencier si je compile la meme application pour des systemes differents) :

Et je m’y place :

Je lis le README qui dit en substance :

[quote]Very easy,
./configure ; make ; su -c “make install”[/quote]

Je fais donc ce qu’on me dit :

Et la :

Tres bien, je cherche le paquet a installer qui manque pour compiler :

Dans la liste apparait libgnomeui-dev que j’installe :

# aptitude install libgnomeui-dev $ ./configure

C’est bon, je peux continuer :

[code]$ make

checkinstall make install[/code]

Je reponds vaguement aux questions posees, pas de problemes, j’obtiens mon paquet .deb :

[quote]You can remove it from your system anytime using:

  dpkg -r gmencoder-0.1.0-sid[/quote]

J’essaye si gmencoder se lance bien, pas de problemes.

Maintenant, indiquer les dependances au paquet .deb :

Je cree le script lsdepend que je recopie de ton tuto dans un editeur de texte, je le place dans /usr/local/bin et je le rend executable :

[code]# cp lsdepend /usr/local/bin/

chmod +x /usr/local/bin/lsdepend[/code]

[quote=“fran.b”]On fait donc tout d’abord l’extraction des fichiers du paquet dans un répertoire (ici gre).
Code:
$ mkdir gre
$ cd gre
$ dpkg-deb -e …/scilab_4.0_i386.deb
$ dpkg-deb -x …/scilab_4.0_i386.deb .
[/quote]

Pourquoi “gre”? Ca peut paraitre idiot, mais dans un premier temps c’est un peu “confusant” (ca se dit ca “confusant”?).

Bon, faisons pareil :

$ mkdir gre $ cd gre $ dpkg-deb -e ../gmencoder-0.1.0-sid_amd64-1_amd64.deb

Jusque la ca va, ca cree bien un repertoire gre/DEBIAN.

Mais :

me renvoie :

[quote]dpkg-deb: --extract a besoin d’un répertoire cible.
Peut-être devriez-vous utiliser dpkg --install ?[/quote]

La je ne sais pas quoi faire, je continue.

[quote=“fran.b”]Ainsi ici, sachant que les binaires sont dans usr/lib/scilab-4.0/bin/
[/quote]

Sachant, certes, toi tu sais mais l’apprenti comme moi? Je cherche donc un equivalant de ces binaires pour mon paquet :

[code]# updatedb

locate gmencoder[/code]

me renvoie :

[quote]/usr/local/bin/gmencoder
/usr/local/share/locale/en/LC_MESSAGES/gmencoder.mo
/usr/local/share/locale/es/LC_MESSAGES/gmencoder.mo
/usr/local/share/pixmaps/gmencoder
/usr/local/share/pixmaps/gmencoder/media-pause.png
/usr/local/share/pixmaps/gmencoder/media-play.png
/usr/share/doc/gmencoder-0.1.0-sid
/usr/share/doc/gmencoder-0.1.0-sid/AUTHORS
/usr/share/doc/gmencoder-0.1.0-sid/ChangeLog
/usr/share/doc/gmencoder-0.1.0-sid/NEWS
/usr/share/doc/gmencoder-0.1.0-sid/README
/var/lib/dpkg/info/gmencoder-0.1.0-sid.conffiles
/var/lib/dpkg/info/gmencoder-0.1.0-sid.list[/quote]

Et la je bloque. Je trouve pas ou je pourrai lancer le script lsdepend. C’est effectivement la que je bloquais aussi lors de mes premeirs essais. :cry:

#3

[quote=“youki”][…]
Je cree le script lsdepend que je recopie de ton tuto dans un editeur de texte, je le place dans /usr/local/bin et je le rend executable :

[code]# cp lsdepend /usr/local/bin/

chmod +x /usr/local/bin/lsdepend[/code]

[quote=“fran.b”]On fait donc tout d’abord l’extraction des fichiers du paquet dans un répertoire (ici gre).
Code:
$ mkdir gre
$ cd gre
$ dpkg-deb -e …/scilab_4.0_i386.deb
$ dpkg-deb -x …/scilab_4.0_i386.deb .
[/quote]

Pourquoi “gre”? Ca peut paraitre idiot, mais dans un premier temps c’est un peu “confusant” (ca se dit ca “confusant”?).
[/quote]gre, truc, foo, bar sont des équivalents, je croyais que c’était connu…[quote]
Bon, faisons pareil :

$ mkdir gre $ cd gre $ dpkg-deb -e ../gmencoder-0.1.0-sid_amd64-1_amd64.deb

Jusque la ca va, ca cree bien un repertoire gre/DEBIAN.

Mais :

me renvoie :

[quote]dpkg-deb: --extract a besoin d’un répertoire cible.
Peut-être devriez-vous utiliser dpkg --install ?[/quote]
[/quote]
Il faut lire avec soin, c’est marqué

[quote]$ mkdir gre
$ cd gre
$ dpkg-deb -e …/scilab_4.0_i386.deb
$ dpkg-deb -x …/scilab_4.0_i386.deb .[/quote] soit donc pour toi

avec un «.» à la fin.

Sachant, certes, toi tu sais mais l’apprenti comme moi? Je cherche donc un equivalant de ces binaires pour mon paquet :[…]
[/quote]
Il faut lire le texte, il y a écrit

donc cela explique l’origine de «gre» et surtout les commandes diverses. Si on se pose des question, un man dpkg-deb renvoie pour -e et -x

[quote] -e, --control archive [répertoire]
Extrait les fichiers de contrôle d’une archive de paquet dans le
répertoire spécifié.

          Quand  aucun répertoire n’est précisé, on utilise un sous-réper‐
          toire DEBIAN du répertoire actuel.
   -x, --extract archive répertoire
          Extrait l’arborescence des fichiers d’un paquet archive dans  le
          répertoire spécifié.

[/quote]qui explique d’un coup les deux commandes et permet éventuellement de voir une erreur de syntaxe. Après effectivement j’aurais pu détailler ces commandes, mais je ne suis pas sûr que dans un article sur la confection des macarons, on explique longuement comment allumer le four… mais c’est un point de vue. Je rectifie le fil…

#4

Ok, j’avais deja remarque pour foo, c’est la premiere fois que je suis confronte a gre, je le saurai maintenant.

Effectivement, au temps pour moi. Le «.» maintenant que je le sais je ne vois que lui, avant je ne l’avais pas vu. Donc tu as raison je devrais lire attentivement.

Et effectivement la commande executee correctement me cree un repertoire …/gre/usr.

:blush: Ben faudra que j’apprenne a allumer un four alors.

Bon, j’ai tout relu (bien j’espere cette fois) donc si je comprends bien je dois lancer le script lsdepend dans gre/usr/local/bin? C’est bien ca, j’ai pas compris de travers cette fois?
La il y a bien les binaires de gmencoder, ca se lance quand je clique dessus en graphique…

Je demande bien parceque dans ton tuto c’est marque ca :

Et je demande parce que j’obtiens ca :

[quote]…/gmencoder-0.1.0-sid-amd64/gre/usr/local/bin$ lsdepend
sh: Syntax error: “(” unexpected[/quote]

Pareil si je specifie bien le chemin du script :

[quote]…/gre/usr/local/bin$ /usr/local/bin/lsdepend
sh: Syntax error: “(” unexpected[/quote]

Quand je compare le script que j’ai copie dans /usr/local/bin et rendu executable avec ce qui se trouve dans ton tuto je ne vois pas de difference pourtant.

C’est marrant, j’ai l’impression d’etre ma copine quand je lui explique quelque chose sur l’ordi et qu’elle comprend pas alors que ca me semble evident.

En tous cas merci de tes reponses.

#5

Hum tu ne serais pas en dash par hasard??? Remplaces /bin/sh par /bin/bash (le passage en dash, ça apporte quoi au juste mis à part des soucis?)

Sinon effectivement, il s’agit de trouver l’endroit où sont les binaires, les éxécutables quoi. Sous scilab, ils sont mis dans

/usr/lib/scilab-4.0/bin

Parfois c’est ailleurs, là je ne peux pas deviner, il s’agit de chercher. Effectivement c’est… mettons elliptique dans mon bazar…

Pour le coup du «four», ce que je veux dire, c’est qu’il faut connaitre un peu la commande dpkg-deb lorsqu’on fait des paquets, je peux cependant indiquer un renvoi au pages de manuel sur ce point.

#6

Heu, ben en fait je me suis jamais pose la question. Je ne sais meme pas encore comment choisir celui par defaut (edit, a ce sujet voir le post suivant). J’ai juste installe mon systeme et j’ai les deux d’installes (du fait des dependances je suppose).

[quote]$ apt-cache policy dash
dash:
Installé : 0.5.5.1-3
Candidat : 0.5.5.1-3[/quote]

[quote]$ apt-cache policy bash
bash:
Installé : 4.1-1
Candidat : 4.1-1[/quote]

Sinon, j’ai bien change le script :

[quote]$ cat /usr/local/bin/lsdepend
#!/bin/bash
find . -type f | xargs ldd 2> /dev/null |
sed -e ‘1,$s/=.*//’ |
sed -e ‘1,$s/^ /dpkg -S /’ | grep -v “:” |
grep “.so” |
sort -u | sh |
sed -e '1,$s/:.//’ |
sort -u |
sed -e ‘1,$s/^/dpkg -l | grep "^[a-zA-Z]\{2\} * /’ | sed -e ‘1,$s/$/ "/’ |sh
[/quote]
qui est bien executable :

[quote]$ ls -l /usr/local/bin/lsdepend
-rwxr-xr-x 1 root root 275 8 févr. 20:57 /usr/local/bin/lsdepend[/quote]

[quote=“fran.b”]Sinon effectivement, il s’agit de trouver l’endroit où sont les binaires, les éxécutables quoi. Sous scilab, ils sont mis dans

/usr/lib/scilab-4.0/bin

Parfois c’est ailleurs, là je ne peux pas deviner, il s’agit de chercher. Effectivement c’est… mettons elliptique dans mon bazar…[/quote]
C’est bien ce que je pensais avoir compris. Donc pour trouver ou est l’executable installe par checkinstall j’avais fait :

qui me renvoit (j’ai enleve ce qui est dans mon /home en rapport avec la compilation) :

[quote]/usr/local/bin/gmencoder
/usr/local/share/locale/en/LC_MESSAGES/gmencoder.mo
/usr/local/share/locale/es/LC_MESSAGES/gmencoder.mo
/usr/local/share/pixmaps/gmencoder
/usr/local/share/pixmaps/gmencoder/media-pause.png
/usr/local/share/pixmaps/gmencoder/media-play.png
/usr/share/doc/gmencoder-0.1.0-sid
/usr/share/doc/gmencoder-0.1.0-sid/AUTHORS
/usr/share/doc/gmencoder-0.1.0-sid/ChangeLog
/usr/share/doc/gmencoder-0.1.0-sid/NEWS
/usr/share/doc/gmencoder-0.1.0-sid/README
/var/lib/dpkg/info/gmencoder-0.1.0-sid.conffiles
/var/lib/dpkg/info/gmencoder-0.1.0-sid.list[/quote]
Donc je pense pas dire de conneries en disant qu’il est dans /usr/local/bin/, mais y’a aussi d’autres binaires d’autres applications dans /usr/local/bin/, c’est ca que j’ai du mal a comprendre, comment lsdepend peut ne prendre en compte que gmencoder si je le lance dans un repertoire ou il y a pleins de binaires?
Essayons tout de meme :

$ cd /usr/local/bin/ $ lsdepend sh: Syntax error: "(" unexpected
Damned!

Il y avait bien ce binaire qui s’est retrouve seul dans /home/(…)/gmencoder-0.1.0-sid-amd64/gre/usr/local/bin, essayons la :

.../gmencoder-0.1.0-sid-amd64/gre/usr/local/bin$ lsdepend sh: Syntax error: "(" unexpected
Re-damned!

Ouais, j’avais compris ca un peu comme “faut pas mettre la charrue avant les boeufs” et qu’avant de me mettre a faire des paquets je ferai bien de connaitre certaines bases. Mais bon l’occasion fait le larron, je vais regarder la commande dpkg-deb de plus pres.

#7

Donc l’interpreteur de commande par defaut. Si j’en crois ces lignes, “le shell par défaut est précisé dans le fichier de configuration /etc/passwd dans le dernier champ de la ligne correspondant à l’utilisateur.”

Hors dans mon /etc/passwd j’ai aucun dash et j’ai bien bash :

[quote]
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
Debian-exim:x:101:103::/var/spool/exim4:/bin/false
statd:x:102:65534::/var/lib/nfs:/bin/false
youki:x:1000:1000:youki,:/home/youki:/bin/bash
messagebus:x:103:106::/var/run/dbus:/bin/false
polkituser:x:104:107:PolicyKit,:/var/run/PolicyKit:/bin/false
haldaemon:x:105:108:Hardware abstraction layer,:/var/run/hald:/bin/false
avahi:x:106:112:Avahi mDNS daemon,:/var/run/avahi-daemon:/bin/false
timidity:x:107:113:TiMidity++ MIDI sequencer service:/etc/timidity:/bin/false
gitdaemon:x:109:65534::/nonexistent:/bin/false
ntop:x:108:114::/var/lib/ntop:/bin/false
zeroinst:x:110:115::/home/zeroinst:/bin/false
sshd:x:111:65534::/var/run/sshd:/usr/sbin/nologin[/quote]

#8

J’ai des doutes la-dessus : j’ai bien bash dans mon /etc/passwd, mais /bin/sh est un lien vers dash !
Et il me semble que sur mon systeme j’ai active dash comme interpreteur sh par defaut…

A ce que je comprends d’un ‘dpkg-reconfigure dash’, bash reste utilise pour l’invite de commande utilisateur, mais par contre c’est dash qui est utilise comme interpreteur pour les scripts utilisant sh.

#9

Ton lsdepend n’est pas bon:

#!/bin/sh find . -type f | xargs ldd 2> /dev/null | sed -e '1,$s/=.*//' | sed -e '1,$s/^ */dpkg -S /' | grep -v ":" | sed -e '1,$s/ (.*$//' | grep "\.so" | sort -u | sh | sed -e '1,$s/:.*//' | sort -u | sed -e '1,$s/^/dpkg -l | grep "^[a-zA-Z]\\{2\\} * /' | sed -e '1,$s/$/ "/' |sh

(5ième ligne entre autres)

#10

[quote=“fran.b”]Ton lsdepend n’est pas bon:

#!/bin/sh find . -type f | xargs ldd 2> /dev/null | sed -e '1,$s/=.*//' | sed -e '1,$s/^ */dpkg -S /' | grep -v ":" | sed -e '1,$s/ (.*$//' | grep "\.so" | sort -u | sh | sed -e '1,$s/:.*//' | sort -u | sed -e '1,$s/^/dpkg -l | grep "^[a-zA-Z]\\{2\\} * /' | sed -e '1,$s/$/ "/' |sh

(5ième ligne entre autres)[/quote]
Tiens, c’est le copier/coller qui l’a fait bugger ou bien? Pourtant j’ai copie-colle celui juste au dessus aussi et ca fonctionne.

J’ai quand meme ca au debut :

[quote]/gmencoder-0.1.0-sid-amd64/gre/usr/local/bin$ lsdepend
dpkg : /lib64/ld-linux-x86-64.so.2 introuvable.
dpkg : linux-vdso.so.1 introuvable.
ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphics - runti
ii libasound2 1.0.21a-1 shared library for ALSA applications
ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit
ii libaudiofile0 0.2.6-8 Open-source version of SGI’s audiofile libra
(etc…)[/quote]

Je ne mets pas tout, c’est long. Mais ca me donne donc ce champ dans le DEBIAN/control :

Je reconstruit le paquet :

[quote]…/gmencoder-0.1.0-sid-amd64$ dpkg-deb -b gre gmencoder-0.1.0-sid_amd64-1_amd64.deb
dpkg-deb : construction du paquet « gmencoder-0.1.0-sid » dans « gmencoder-0.1.0-sid_amd64-1_amd64.deb ».[/quote]

J’ai installe le paquet sur le portable, malheureusement il n’a pas installe de dependances sans doute parce qu’elles etaient deja la. Gmencoder de lance bien.
Je vais donc essayer avec un autre paquet dont je suis sur qu’il n’y aura pas toutes les dependances sur le portable avant de marquer comme resolu.

#11

Les messages d’erreurs sont les librairies pour lesquelles le script n’a pas trouvé le paquet d’origine (libc6 en l’occurrence), la plupart du temps, tu peux ignorer.

#12

Ok, je viens d’essayer en compilant ardour 2.6. Tout se passe bien, lsdepend fonctionne apres avoir trouve les binaires dans …/gre/usr/, le paquet reconstruit ensuite prend bien en compte les dependances quand j’essaye de l’installer sur le portable.
Me reste plus qu’a me mettre a la fabrication de paquets .deb en utilisant dh_make d’ici peu.

Merci fran.b :smiley:

#13

Une derniere question (jusqu’a la prochaine tout du moins), est-ce qu’il y a une nomenclature “officielle” pour nommer ses paquets .deb?

Edit : Je suppose que ca repond a la question…

[quote=“http://www.debian.org/doc/manuals/maint-guide/ch-first.fr.html#s-namever”]2.3 Les noms et versions des paquets

Vous devriez commencer la création du paquet avec un répertoire source complètement propre (originel), ou plus simplement avec les sources fraîchement décompressées.

Pour que le paquet soit correctement construit, vous devez changer le nom du programme en minuscule (si ce n’est déjà fait), et vous devriez changer le répertoire source en -.

Si le nom du programme consiste en plus d’un mot, réduisez-le à un mot, ou faites une abréviation. Par exemple, le paquet du programme « John’s little editor for X » serait nommé johnledx, ou jle4x, ou quoi que vous vouliez, aussi longtemps qu’il reste sous une limite raisonnable, en général 20 caractères.

Vérifiez aussi la version exacte du programme (qui sera inclus dans la version du paquet). Si ce logiciel n’est pas numéroté avec un numéro de version comme X.Y.Z, mais avec une date de distribution, vous pouvez utiliser cette date comme numéro de version, avec comme préfixe « 0.0. » (juste au cas où les responsables amont décident de distribuer une jolie version comme 1.0). Donc, si la date est le 19 décembre 1998, vous pouvez utilisez 0.0.19981219 comme chaîne pour la version.

Certains ne seront pas numérotés du tout, auquel cas vous devriez contacter le responsable amont pour voir s’il a une autre méthode de gestion des révisions. [/quote]

#14

Autant ça n’est pas trop dur de faire des paquets, autant il est délicat de gérer des paquets source. Dans un tel cas, tu dois prévoir un scenario de compilation sur toutes les architectures et le paquet doit être conforme aux standards debian. Par ailleurs, on ne touche pas aux sources d’origine, on les patche. J’avoue que je n’ai jamais été jusqu’à la perfection loin de là. La fabrication d’un paquet peut se révéler un cauchemar; ainsi le paquet camllight que je gère pour debian et ubuntu est une usine à gaz incroyable (c’était un de mes premiers paquets), il fallait adapter des Makefile existants avec des config en dur à modifier, compiler une première version du compilateur nécessaire pour compiler la totalité du paquet. Bref, la construction du debian/rules peut être délicate. Par contre ça peut se faire sans maitriser du tout les automake, j’en suis la preuve.

#15

Ben j’ai de toutes facons pas l’intention de me mettre a entretenir des paquets serieusement. Juste de comprendre un peu mieux le schmilblik et de m’amuser un peu. C’est quand meme pratique de pouvoir se compiler et packager certaines sources. Et comme je suis bien incapable de les patcher, je n’ai pas d’autres ambitions.