Rechercher

• Accueil -
• Archives

Commentaires

1. Fabrice
samedi 5 février 2005, 23:59

Hallo, <quote>Comment fait-on pour ajouter un fichier binaire quand on construit un package debian ? Exemple je veux ajouter une icône parce qu’il n’y en a pas de fourni avec la tarball, et cette icône est en PNG. Comment construit-il le diff puisque c’est du binaire ?</quote>

Tu utilises uuencode/uudecode et dpkg-source te fichera la paix.

2. gauret
dimanche 6 février 2005, 23:46

@Fabrice :

Ah, je vois, tu poses le fichier uuencodé dans ton dossier debian, et ensuite tu le uudécodes dans la cible install du fichier rules avant de le placer au bon endroit dans l'arborescence. Rusé, effectivement. Un peu lourd, mais c'est vrai qu'on ajoute rarement des fichiers binaires finalement. Merci !

3. Clément 'nodens' Hermann
mercredi 23 novembre 2005, 09:14

Bonjour,

Personnellement, c'est un peu le contraire : j'ai d'abord travaillé sous redhat / mandrake, puis je suis passé à debian. D'ailleurs c'est moi qui ait poussé pour qu'on utilise debian au boulot quand il a fallu choisir entre elle et fedora

Quelques commentaires sur tes commentaires, donc : { On peut signer individuellement un package avec GPG. C'est très important. }

Rectification : on peut signer un binaire. tous les paquets officiels sont signés par les mainteneurs sous forme de source, et sont construit par les buildd (build-daemons) du projet avant d'être déposés dans l'archive debian (moment auquel la signature du fichier Packages de l'archive est signée, pour authentifier l'archive). Le fait de signer un binaire est plus direct, mais je préfère que ce ne soit pas le développeur qui compile le binaire, plutôt le buildd (dans l'idéal, le buildd devrait signer les binaires).

{- Plus simple à fabriquer de toutes pièces. OK, sachant que je package des RPM depuis relativement longtemps, ce point est peut-être biaisé, mais je trouve qu'il est plus simple de manipuler des scripts shell que des makefiles (mais je suis plus admin que développeur aussi) }

Ca se discute. Très personnellement, je suis plus admin que développeur également, mais je trouve les paquets debian plus simples à manipuler. dh_make et CDBS sont autant de moyens de créer un paquet rapidement. Dans le cas d'un paquet simple (configure make make install, sans subtilité ni patch trop complexe), c'est très vite fait, il n'y a plus qu'a remplir les fichiers control (description / dépendances non automatiques) et enlever les examples inutiles. Bon, pour le faire inclure dans Debian il y a généralement un peu plus de travail... Et évidemment, dans les cas tordu, un Makefile peut faciliter la vie, mais est aussi beaucoup plus tordu à utiliser pour de pauvres admins comme toi et moi

- Il est plus facile de savoir quels patches on été appliqués à la source, parce qu'ils sont dans des fichiers séparés (avec nom et version). Chez Debian il y a dpatch qui permet de faire ça mais ce n'est pas systématique (et apparemment pas majoritaire).

On est d'accord : dpatch est sous-utilisé pour le moment Cela dit, j'ignore comment ça se passe quand on crée un rpm, mais même avec dpatch, si on a besoin de patcher le source (mettons, le paquet) juste pour l'empaqueter, il suffit de le modifier, et dpkg-buildpackage créera tout seul le patch par rapport au sources (ce sera dans le même patch que le répertoire debian/).

{- On peut utiliser des macros prédéfinies pour se simplifier la vie et pour garder une uniformité au sein de la distrib. Debhelper fournit ce genre de services, mais il est beaucoup plus complexe et moins automatique que dans RPM. Par exemple, dans RPM il y a des macros pour les chemins des autotools (ex : %_libdir pour /usr/lib). Ca a permit d'adapter facilement la distrib au 64bits, en définissant simplement %_lib en /lib64 au lieu de /lib. }

Moins automatique ? Je ne comprends pas. je ne vois pas dans quel mesure il y a quoi que ce soit à faire pour changer ce type de chemin... A partir du moment où on a un port officiel (donc buildd et une équipe de porteurs), le développeur n'a pas besoin de s'en préoccuper sauf problème (rare). les paquets sources sont strictement les mêmes. Pour créér le port, généralement ça implique un peu de bricolage, évidemment. Mais c'est le cas de n'importe quelle distribution dans la première phase d'un tel port. Par ailleurs, je n'ai presque jamais passé (ni vu passer) de paramètre particulier aux outils debhelper (mais je n'ai pas créé de paquets extrêmement complexe non plus).

Quant à l'uniformité, elle est garantie par le respect de la charte debian (debian policy), la version à laquelle on se conforme devant figurer dans les champs de contrôle du paquet.

{

• Possibilté de dépendre d'un fichier (une librairie, un programme) et pas seulement d'un autre package}

C'est un choix de design. Effectivement ça parait dommage, mais le choix a été de fournir de préférence la possibilité de faire des paquets «dummy» à la place. L'argument généralement avancé est l'impossibilité de distinguer deux fichiers identiques provenant de paquets différents et en conflit. Le principe est que le rescpect des dépendances doit garantir au maximum le fonctionnement. Ca simplifie également le débogage. Ca complique parfois la vie, cependant.

Différences supplémentaires observées :

• dpkg est plus rapide. C'est peut-être entièrement subjectif, mais c'est mon impression
• RPM a un feature qui me manque : le --verify. On peut vérifier les sommes MD5 des fichiers avec dpkg, mais pas l'appartenance ni les permissions, ni les dates de création. En tout cas pas de manière automatique. Je crois que ça doit être mon premier rapport de bogue à debian, il traine toujours en wishlist quelque part

Pour la construction des paquets debian, la méthode indiquée fonctionne, mais j'utilise de préférence dpkg-buildpackage :

dpkg-buildpackage -rfakeroot -us -uc (le -us -uc signifie qu'on ne veut pas signer les fichier sources et changes).

voilà, mes 0.02 €, tout ça....

4. gauret
jeudi 24 novembre 2005, 20:58

@Clément 'nodens' Hermann :

Déjà, merci pour ton avis, c'est agréable d'avoir un point de vue détaillé et argumenté

> Le fait de signer un binaire est plus direct, mais je préfère que ce ne soit pas le développeur qui compile le binaire, plutôt le buildd (dans l'idéal, le buildd devrait signer les binaires).

Evidemment, pour les packages de la distrib, tout est signé avec la clef de la distrib. La question se pose quand tu veux distribuer un package. Sous Debian, si tu veux qu'il soit signé, il faut que tu créé un répo apt, et que tu signes le fichier Packages. Tu ne peux pas juste filer le binaire, avec la signature incluse. C'est encore plus problématique si tu ne veux pas distribuer ton package à tout le monde, mais que tu veux qu'on puisse quand même vérifier la signature (disons, à des clients par exemple).

> Ca se discute. Très personnellement, je suis plus admin que développeur également, mais je trouve les paquets debian plus simples à manipuler.

Oui, j'imagine que c'est très subjectif (mais j'ai dit que j'étais biaisé ). Les packages debian deviennent vraiment très complexes quand tu as plus d'une tarball d'origine, alors que de ce côté là rpm s'en sort bien. Bref, ça doit dépendre des utilisations, et des goûts

> Cela dit, j'ignore comment ça se passe quand on crée un rpm, mais même avec dpatch, si on a besoin de patcher le source (mettons, le paquet) juste pour l'empaqueter, il suffit de le modifier, et dpkg-buildpackage créera tout seul le patch par rapport au sources (ce sera dans le même patch que le répertoire debian/).

Oui, mais ce qui me sort par les trous de nez dans cette méthode, c'est qu'ensuite ton patch est inclus dans le gros fichier .diff de ton package, qui contient aussi tous les fichiers de debian/. Avec deux ou 3 patches, ça devient totalement illisible, et finalement tu ne sais plus ce que tu as patché ou les modifications que tu as faites. Pire, quelqu'un qui regarde ton package ne peut plus le savoir non plus (et si il essaye, il bouffera une boîte d'aspirines...)

Avec rpm est fourni un petit script de 10 lignes qui permet de générer facilement des patches. La méthode est la suivante : tu sauvegarde ton fichier d'origine en .gcc4fix par exemple, et tu lances "gendiff repertoire_des_sources .gcc4fix". Sur la sortie standard apparait ton diff (en fait celui de tous les fichiers se terminant par .gcc4fix. C'est tellement con et pratique que je vais le copier là, tiens <code> #!/bin/sh

[ -z "$1" -o -z "$2" ] && { # usage echo "usage: $0 <directory> <diff-extension>" 1>&2 exit 1 }

find $1 ( -name "*$2" -o -name ".*$2" ) -print | while read f; do U=-u [ "`basename $f`" = "ChangeLog$2" ] && U=-U0 # diff $U $f `echo $f | sed s/$2$//` if [ -r "$f" ]; then diff $U "$f" "$f%$2" else diff $U /dev/null "$f%$2" fi done </code>

Voilà. Immensément pratique, et pas que pour faire des rpms. Je copie ça souvent sur mes serveurs debian, c'est nickel pour faire des patches. Bref

> Moins automatique ? Je ne comprends pas. je ne vois pas dans quel mesure il y a quoi que ce soit à faire pour changer ce type de chemin

Ben si tu n'as pas de macro pour le chemin /lib par exemple, quand tu as besoin de le changer en /lib64, comme pour amd64, tu dois le changer dans tous les packages. Avec des rpms, tu recompiles bêtement tous tes packages avec un --define "lib lib64" et sauf exception, c'est bon. Le configure fera des --libdir=/usr/lib64 puisqu'il dépend de la macro (il y a même une macro pour configure, avec les bonnes options de base de la distrib). Ces macros permettent plus facilement de faire des changements sur tout la distrib d'un coup. Voilà, j'espère que j'ai été plus clair (j'en ai pas forcément plus raison, hein )

> le choix a été de fournir de préférence la possibilité de faire des paquets « dummy » à la place

Avec rpm on peut mettre un tag "Provides: " et faire dépendre d'autres packages du contenu. Exemple : apache "Provides: webserver", et les autres rpms peuvent mettre "Requires: webserver". Pour faire un paquet "dummy", il suffit de faire un packages qui n'a pas de fichier, mais que des dépendances.

> dpkg est plus rapide

Hmm, je suis d'accord, mais ça, globalement, je m'en..... préoccupe peu

Merci beaucoup pour ton avis sur la question !

5. Clément 'nodens' Hermann
vendredi 25 novembre 2005, 17:44

@gauret :

Evidemment, pour les packages de la distrib, tout est signé avec la clef de la distrib. La question se pose quand tu veux distribuer un package. Sous Debian, si tu veux qu'il soit signé, il faut que tu créé un répo apt, et que tu signes le fichier Packages. Tu ne peux pas juste filer le binaire, avec la signature incluse. C'est encore plus problématique si tu ne veux pas distribuer ton package à tout le monde, mais que tu veux qu'on puisse quand même vérifier la signature (disons, à des clients par exemple).

Je vois ce que tu veux dire. Mais dans ce cas, si tu ne fait pas de repository, tu dois distribuer la signature séparément. Tu peux donc aussi bien distribuer un md5 signé du binaire avec, puisqu'il y aura nécessairement une manipulation pour vérifier la signature... Et si tu as plusieurs paquet, y'a-t-il une bonne raison pour ne pas faire un repository (simple) ?

Oui, mais ce qui me sort par les trous de nez dans cette méthode, c'est qu'ensuite ton patch est inclus dans le gros fichier .diff de ton package, qui contient aussi tous les fichiers de debian/. Avec deux ou 3 patches, ça devient totalement illisible, et finalement tu ne sais plus ce que tu as patché ou les modifications que tu as faites. Pire, quelqu'un qui regarde ton package ne peut plus le savoir non plus (et si il essaye, il bouffera une boîte d'aspirines...)

C'est pas faux C'est pourquoi je milite pour l'usage généralisé de dpatch. Ce n'est effectivement pas idiot de réutiliser le script de redhat, j'y penserai à l'occasion.

{ Ben si tu n'as pas de macro pour le chemin /lib par exemple, quand tu as besoin de le changer en /lib64, comme pour amd64, tu dois le changer dans tous les packages. Avec des rpms, tu recompiles bêtement tous tes packages avec un -define "lib lib64" et sauf exception, c'est bon. Le configure fera des -libdir=/usr/lib64 puisqu'il dépend de la macro (il y a même une macro pour configure, avec les bonnes options de base de la distrib). Ces macros permettent plus facilement de faire des changements sur tout la distrib d'un coup. Voilà, j'espère que j'ai été plus clair (j'en ai pas forcément plus raison, hein )}

Ben je peux difficilement être d'accord avec toi puisque de mon point de vue, sur un système 64 bits on ne doit avoir que ça... ce qui rend ce genre de choses inutiles. Si tu veux mélanger, l'éditeur de liens dynamique sert à ça... ld.so.conf est ton ami

C'est une méthode propre, intéressante quand tu compile dans ton coin, mais il faudrait toujours compiler ses paquets dans un chroot quand tu n'es pas sur le système final, donc on peut s'en passer.

{ Avec rpm on peut mettre un tag "Provides : " et faire dépendre d'autres packages du contenu. Exemple : apache "Provides : webserver", et les autres rpms peuvent mettre "Requires : webserver". Pour faire un paquet "dummy", il suffit de faire un packages qui n'a pas de fichier, mais que des dépendances. }

Oui, je n'étais pas en train de dire qu'on ne pouvait pas faire de paquets dummy avec rpm (cela dit là il s'agit plutôt de ce qu'on appelle un paquet virtuel chez debian), mais plutôt que l'absence de dépendance sur les fichiers n'était pas un vrai problème.... D'ailleurs ça aurait plutôt tendance à inciter au laxisme... C'est un des artifices de debian pour inciter à prêter attention à la cohérence globale, décourager les paquets vite et mal faits, et donc contribuer à la bonne image de marque de la distribution.

Merci beaucoup pour ton avis sur la question !

De rien, pour une fois qu'on discute de ce genre de sujet entre gens civilisés sans troller madebiancélebienredhatcédémaichans

6. gauret
dimanche 27 novembre 2005, 12:00

@Clément 'nodens' Hermann :

> Mais dans ce cas, si tu ne fait pas de repository, tu dois distribuer la signature séparément.

Justement pas, la signature est intégrée dans le format RPM. Le package contient la signature de son contenu dans l'en-tête. Un seul fichier à distribuer, et tu peux vérifier la signature.

> Ben je peux difficilement être d'accord avec toi puisque de mon point de vue, sur un système 64 bits on ne doit avoir que ça... ce qui rend ce genre de choses inutiles.

Malheureusement, tout ne compile pas encore en 64bits. Le plus connu est OpenOffice, mais il y en a d'autres. Et il y a les programmes que tu dois avoir en 32bits si tu veux utiliser un plugin qui est 32bits-only (ex: Firefox et le plugin Flash©®). Et il y a d'autres cas. Donc un système mixte est quasi-obligatoire pour un poste de bureau en 64bits actuellement (ok, on peut utiliser abiword et ne pas utiliser de flash, mais bon, dans les faits, un système mixte est très utile)

> C'est un des artifices de debian pour inciter à prêter attention à la cohérence globale, décourager les paquets vite et mal faits, et donc contribuer à la bonne image de marque de la distribution.

Ou comment transformer un défaut en avantage... ;p Petite citation :
"Make everything as simple as possible, but not simpler." -- Albert Einstein

Ce n'est pas en complexifiant le système de packages qu'on en assure la qualité. C'est plutôt avec des outils comme lintian et rpmlint.

7. maouth
lundi 24 avril 2006, 17:16

@gauret :

> C'est un des artifices de debian pour inciter à prêter attention à la cohérence globale, décourager les paquets vite et mal faits, et donc contribuer à la bonne image de marque de la distribution.

c'est vrai c'est la merde les dependances sur un fichier . j'ai un ... qui a créé un dependance sur un fichier du coup tu sais pas dans quel paquet tu doit installé voila une explication d'une experience sur le vis on doit pouvoir le faire mais c'est pas pratique

8. gauret
lundi 24 avril 2006, 17:32

@maouth :

<quote>c'est vrai c'est la merde les dependances sur un fichier . j'ai un ... qui a créé un dependance sur un fichier du coup tu sais pas dans quel paquet tu doit installé voila une explication d'une experience sur le vis on doit pouvoir le faire mais c'est pas pratique</quote>

Perso je trouve que les dépendances sur un fichier sont une fonctionnalité indispensable pour un système de package qui veut sortir de son cocon (c'est à dire être utilisé par d'autres gens que ceux qui font la distrib).

Parfois tu as besoin de la présence d'une lib, quelquesoit le nom du package dans laquelle elle se trouve. Donc si ton programme packagé dépend de ce fichier, ton package doit pouvoir refléter cette dépendance.

Ensuite libre à toi d'utiliser cette fonctionnalité-là ou pas, mais sache que le gestionnaire de packages te permet de savoir dans quel package se trouve ce fichier (repoquery --whatprovides tonfichier.so ou urpmf sous Mandriva)

Et de toute façon ton resolveur de dépendances (yum, urpmi, smart, etc...) s'occupera de ça tout seul, bref, c'est pas censé être visible pour l'utilisateur final (sauf si il installe le rpm à la main avec l'outil rpm, mais là il aura les mêmes problèmes qu'un utilisateur qui installe un .deb avec dpkg -i)

9. Misc
lundi 4 mai 2009, 20:21

Tu as oublié le support du md5 de base dans rpm, pour vérifier les fichiers. Je suis pas sur que le .deb propose ça ( ou alors, je veut bien qu'on me dise l'équivalent de rpm -V ).

Et je sais pas si le support du multiarch est fini ( http://multiarch.alioth.debian.org/multiarch-hp-report.pdf ).

Pour ma part, j'ai déjà fait des paquets rpm, des .deb, des ports pour macports et gentoo, et très franchement, je pense que les paquets gentoo ou macports sont bien plus simple à faire, via un système qui ressemble à de l'héritage afin de minimiser le code à écrire.

Ensuite, c'est vrai qu'il y a moins de contraintes pour le packageur, chez gentoo et macports, donc forcement, ça me semble plus facile.

10. Aurélien Bompard
lundi 4 mai 2009, 21:06

@Misc :

Anéfé, j'ai oublié la vérification intégrée à RPM, pour tous les fichiers (dpkg a ça pour les fichiers de conf si ma mémoire est bonne, pour savoir comment gérer les modifications).

La notion d'héritage se retrouve dans RPM avec les macros et dans dpkg avec debhelper, mais c'est vrai que ce n'est pas du type des ports Gentoo ou FreeBSD. Ca pourrait être intéressant de faire évoluer RPM/dpkg dans ce sens d'ailleurs. Un fichier spec modèle pour les paquets python, perl, ruby, php-pear, etc., un fichier modèle pour une bibliothèque, pour un démon système, etc. Ça pourrait vraiment aider.

Le top serait que ce soit géré dans RPM.org, puis éventuellement spécialisé dans chaque distribution si besoin... mais pas trop ! On a déjà beaucoup divergé dans les macros disponibles entre les distribs utilisatrices de RPM, partiellement à cause de l'inactivité de RPM lui-même. Ce serait bien d'essayer de reconverger un peu, même si on arrivera probablement jamais à des modèles identiques.

Enfin, on peut rêver...

11. Adam Williamson
mardi 5 mai 2009, 00:44

@gauret :

Mandriva has already implemented Debian-style Suggests: dependencies, starting several versions back (I forget exactly which, could be 2008). urpmi treats them the same way apt-get treats them in Debian; they get installed as dependencies by default but can be removed without triggering the removal of the package that 'depends' on them, and there is a command-line option for *not* installing suggested dependencies by default.

12. Aurélien Bompard
mardi 5 mai 2009, 07:25

@Adam Williamson :

I did not know you could read French, Adam Nice !

I discovered that when I installed version 2008.0 (I use Mandriva at work). At first I thought it was because they used rpm5.org's version of rpm, but maybe not.

"Suggests" are nice, but in urpmi and in apt I think there is a UI problem. I think they should be a opt-in, something like:

"The packages you want to install suggest these additional packages:

• foo1 (suggested by bar1)
• foo2 (suggested by bar2)

Do you want to accept them all (a), choose one-by-one (o), or refuse them all (n) ?"

And in non-interactive mode, they should all be ignored. Debian relies on them for safe dist-upgrading, I think it's a mistake, they should be entirely optional. But nice to have

I don't know how it's implemented in Mandriva, but the Suggests feature is in upstream (rpm.org) RPM, so it may land in Fedora soon. That's cool.

Abonnement aux commentaires

S'abonner pour recevoir les commentaires suivants par email

La discussion continue ailleurs