Trollicide

Principales différences entre packages RPM et Debian

jeudi 27 janvier 2005, par Aurélien Bompard

Répondre à cet article

8 Messages de forum

• > Principales différences entre packages RPM et Debian

  5 février 2005 23:59, par Fabrice

  Hallo,

  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 ?

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

  Répondre à ce message

  • > Principales différences entre packages RPM et Debian 6 février 2005 23:46, par gauret

    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 !

    Répondre à ce message

• Principales différences entre packages RPM et Debian

  23 novembre 2005 09:14, par Clément ’nodens’ Hermann

  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....

  Répondre à ce message

  • Principales différences entre packages RPM et Debian 24 novembre 2005 20:58, par gauret

    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 :)

    
#!/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


    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 !

    Répondre à ce message

    • Principales différences entre packages RPM et Debian 25 novembre 2005 17:44, par Clément ’nodens’ Hermann

      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 ;)

      Répondre à ce message

      • Principales différences entre packages RPM et Debian 27 novembre 2005 12:00, par gauret

        > 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.

        Répondre à ce message

        • Principales différences entre packages RPM et Debian 24 avril 2006 17:16, par maouth

          > 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

          Répondre à ce message

          • Principales différences entre packages RPM et Debian 24 avril 2006 17:32, par gauret

            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

            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)

            Répondre à ce message

Navigation