[empaqueté] opencv 1.1

Programmation
#1

Salut

Une nouvelle version de opencv est disponible sur sourceforge : la 1.1pre1.
La version actuelle dans SID (et peut-être Lenny) est la 1.0.0. Elle se décline en 3 paquets debian principaux :

  • libcv1
  • libcvaux1
  • libhighgui1
    Plus les paquets -dev, de la doc et un wrapper python.
    Hier j’ai fait un empaquetage debian pour cette nouvelle version en repartant de 0 au niveau du changelog (->Initial release) et j’ai généré les paquets suivant :
  • libcv1.1
  • libcvaux1.1
  • libhighgui1.1

Mais je me retrouve avec un dilemme :
Soit je conserve cette structure et je dois refaire mes autres paquets qui dépendent d’opencv en stipulant les dépendances sur les versions 1.1 plutôt que 1.
Soit je refais l’empaquetage d’opencv sur la base d’une version 1.1.0-1 mais qui me génère les paquets libcv1, libcvaux1… Et je n’ai plus à refaire mes autres paquets perso. Par contre je dois faire un peu attention au numéro de révision.

Etant donné que je ne suis pas encore très à l’aise avec l’empaquetage je me demande quelle est la meilleure solution.

#2

La 2, pour avoir été fréquemment dans cette situation, c’est une source de soucis à venir de s’écarter de la structure d’un paquet existant dans Debian et d’en modifier le nom. Le principe est simple: tu mets tes paquets dans un dépot personnel prioritaire, et tu installes par apt-get.

#3

ok
merci du conseil
je vais lancer ça

#4

Fais même attention au numéro de version. Pour les paquets clamav, j’ai longtemps fait des mises à jour sur clamav parce que volotile n’existait pas encore puis réagissait trop longtemps et pas (croyais je) pour potato/woody. Les numéros de versions étaient backport-0.82 par exemple et non 0.82. J’ai récemment recollé à la dénomination de volatile mais j’ai du mettre quelques personnes dans la panade: Ces personnes utilisaient mon dépot et n’ont pas eu la mise à jour de clamav (remarque que ça m’a enlevé de la pression, quand volatile n’existait pas ça se justifiait mais maintenant c’est moins critique). Pense à cezux qui utiliseront tes paquets même si il n’y en a qu’un.

#5

Donc pour résumer et voir si je ne me goure pas :

  • la version actuelle sous Lenny/Sid est 1.0.0-6
    paquets libcv1…
  • sous Etch 0.9.7-4
    paquets libcv…
  • je me gère aussi un backport-1.0.0-4 sous Etch
    paquets libcv1…
  • la version que je vais faire (toujours pour Etch) : 1.1.0-1
    paquets libcv1…

Donc normalement si je me colle la 1.1.0-1 sur un dépôt je ne met personne dans la panade et je peux même faire des révisions 1.1.0-2, 1.1.0-3…tant qu’il n’y a pas de .deb officiel.

#6

Encore une petite question.
Bon soit je n’ai pas encore suffisamment compris l’empaquetage debian, soit je fais une connerie avec mon automake. Une combinaison des 2 n’est pas à exclure.

J’explique : j’ai fait mon empaquetage d’opencv 1.1 en suivant les conseils de fran.b. Tout s’est bien passé car je me suis inspiré de l’empaquetage des .deb officiels.
J’installe ma nouvelle version…pas de stress

J’installe un paquet deb perso fait avec l’ancienne version backport-1.0.0-4, pas de soucis.
Je le lance et j’ai le message suivant :

vidalert: error while loading shared libraries: libcxcore.so.1: cannot open shared object file: No such file or directory
Et pour cause qu’il ne trouve pas libcxcore.so.1, mon paquet lui a généré le lien libcxcore.so.2.

Alors du coup je suis en train de regarder du côté de mon debian/rules pour comprendre comment est généré le lien.
Mais il est possible que le soucis vienne de mon autre paquet…compilé avec les pieds.

#7

Bon, manifestement ce qui m’arrive est normal et faut recompiler ses programmes avec la nouvelle librairie.
Chez Red Hat ils ont même packagé le bouzin en libcv2…mais moi ça ne me plait pas.

Du coup j’ai géré le truc au niveau du debian/control de cette sorte :

Package: libcv1 Section: libs Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Conflicts: libcv1 (<< 1.1.0-1) Replaces: libcv1 (<< 1.1.0-1)
Comme ça les paquets construits avec l’ancienne version vont se faire dégager.

Pour les 3 pelés et les 2 tondus qui pourraient être intéressés je mettrait les paquets sur deb-indus.org dans la soirée.

#8

Comment sont fabriquées les dépendances, usuellement les dépendances avec les librairies sont fabriquées automatiquement, un script parcourt les binaires et regardes les librairies utilisées et le paquet où elles sont. C’est bizarre qu’utilisant libcxcore.so.1, il ne l’ait pas mis dans les dépendances…

#9

Et bien pour tout te dire je me suis inspiré de l’empaquetage de la version 1.0.0 qui est sur les dépôts officiels.
Pour les dépendances j’ai effectivement fait tourné le script qui est dans le manuel du nouveau responsable debian.
Pour info le voici :

strace -f -o /tmp/log ./configure # ou make à la place de ./configure, si votre paquet n'utilise pas autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done
Mais il me renvoyait une liste longue comme le bras.
Donc je me suis borné à utiliser les variables de substitution que sont ${shlibs:Depends}, ${misc:Depends} et qui dont effectivement alimentées par un script.
Après j’ai utilisé les champs conflict et replace uniquement car je récupérais un .so.2 au lieu du .so.1.
D’ailleurs en prenant le tarball de sourceforge je récupère la même chose après :

./configure make make install ldconfig

#10

Hum, le paquet libcv devrait s’appeler libcv2 du coup, puis tu fais un conflict avec libcv1. Tu peux suivre par exemple les évolutions de libclamav1 puis 2,3 et maintenant 4…

#11

Certes, j’y ai pensé et d’ailleurs c’est ce qui a été fait pour l’empaquetage rpm.
Ce qui m’a gêné c’est que la lib est encore en version 1, mais ça n’a effectivement rien à voir avec le nom du paquet.
Je vais peut-être aller demander sur la liste de dev pkg-scicomp comment ils voient le truc vu que c’est eux qui feront le paquet officiel s’il voit le jour.