Re: Création d'un paquet Debian et dépendance vis à vis de Python
Bonjour, :)
On 29/06/2015 03:55, valentin OVD wrote:
> Je crois me souvenir qu'un paquet source debian d'après la policy doit pouvoir se compiler hors ligne sans accès a un truc extérieur.
Oui, absolument... Enfin, ils disposent tout de même *en* *local*
des sources du paquet (forcément) et aussi d'un dépôt Debian pour
pouvoir installer les dépendances.
Personnellement, je ne dispose pas de toute l'infra de build de
Debian alors, dans mon cas, j'ai une petite VM Jessie isssue d'une
« fresh install », je télécharge via git les sources du paquet (pas
trop le choix) et j'installe les build-dépendances du paquet via
Internet (pas trop le choix n'ont plus n'ayant pas de miroir Debian
sur mon réseau local). Et enfin, il y a le build. Et là, effectivement,
si durant le build il y a le moindre accès à Internet, c'est très
mal. Ce n'est pas le cas avec mon paquet donc tout va bien. ;)
J'ai déjà été en contact avec un ftpmaster qui m'a indiqué que le
paquet était Ok. J'avais juste fait une chose qui le lui plaisait
pas (et qui a été la raison d'un rejet dans un premier temps) :
j'avais scindé le paquet source en 2 paquets binaires car ça me
semblait plus logique (un paquet pour l'outil en lui-même et un
autre pour le plugin Inkscape wrapper de l'outil en question). Mais
étant donné que les paquets étaient tout petits (en taille), le
ftpmaster a estimé que c'était mieux d'avoir un seul paquet binaire
issu du paquet source. Pour le reste ça semblait ok. Actuellement,
j'attends confirmation.
> Après c'est différent si c'est un système de snapshot qui copie un snapshot du git dans un paquet source. (J'aurais p-têtre du regarder le paquet avant de faire un commentaire sur cela).
[...]
>>> Depends: python, python:any (<< 2.8), python:any (>= 2.7.5-5~), python-tk, python-pil | python-imaging, libjs-jquery
>>>
>>> Et là, déjà je vois du « python:any », d'où ça sort ce machin ?
>>> Qu'est-ce que c'est ?
> Any signifie toutes les architectures.
Oui, et cette chaîne, issue de la substitution de « ${python:Depends} »
dans le fichier "control" est apparue en cours de route sur Jessie.
Lors de mes premiers builds sur Jessie, elle n'apparaissait pas. Et
de plus, cette chaîne n'est pas comprise par une Wheezy lors d'une
installation, hélas.
> Le fautif doit être ${python:Depends}.
Oui, j'avais bien vu cela. Ceci étant, je dirais plutôt que « le fautif »
c'est une màj sur Jessie (j'ignore laquelle) qui a fait que cette variable
a été du jour du lendemain remplacée par une chaîne qu'une Wheezy ne sait
pas interpréter correctement.
Après, je mets « le fautif » avec des guillemets car je ne sais pas si
on peut faire le reproche à Debian qu'un paquet buildé sur Jessie ne
soit plus compatible Wheezy. Je constate simplement que dans le cas de
mon paquet, le build sur Jessie me donnait un paquet compatible Wheezy
sans avoir à faire quoi que ce soit et que suite à une màj sur Jessie
ça n'a plus été le cas.
> Methode 1 : En précisant manuellement les dépendances python
Alors, c'est pour l'instant la méthode que globalement j'utilise.
Pour le paquet que je propose à Debian, j'ai bien sûr laissé la
variable ${python:Depends} mais ensuite, pour le paquet que je
builde et que je dépose sur notre dépôt, j'ai mis manuellement
la ligne de dépendances python compatible Wheezy *et* Jessie.
Mais je trouve que ce n'est pas super satisfaisant comme méthode.
> ou Methode 2 : de rebuild le paquet sous wheezy.
Oui, c'est une autre possibilité. Comme je préfère avoir un seul
paquet qui marche pour Wheezy et Jessie, j'ai opté pour la méthode
1.
>>> Comment le faire de manière propre et respectueuse de la
>>> Debian policy ? (En effet, je caresse l'espoir de faire intégrer
>>> ce paquet dans les dépôts Debian officiels et donc il faut
>>> que ce soit fait de manière irréprochable ;)).
> Avec la deuxième méthode.
Ok.
> Et checker avec le magnifique lintian si il n'y a pas d'autre problèmes.
J'utilise lintian et il m'a fallu un certain temps avant de n'avoir plus
aucun warning. ;) Ceci étant, c'est du coup super formateur.
> Je rappel aussi que ton paquet ne pourra malheureusement pas être intégré à Jessie ou Wheezy.
Oui, tout à fait. Je le savais dès le départ. En fait, il y a d'un côté
le paquet que je propose à Debian. Pour celui-là je laisse les sources
du paquet en l'état et son build donnera très probablement un paquet binaire
qui ne sera pas installable sur Wheezy mais dans ce cas je m'en fiche vu
que le paquet ne sera de toute façon pas dispo sur Wheezy (et sur Jessie
aussi). Mais il y aussi le paquet que je propose sur notre dépôt « maison »,
et celui-là je souhaite qu'il soit installable sur Wheezy et sur Jessie (et
si possible de manière élégante par rapport à mon souci avec la variable
${python:Depends}).
> J'espère avoir pu apporter de l'aide.
Oui dans le sens où tu me confortes dans le choix que j'ai fait et dans
l'idée que mon problème ne semble possible à résoudre d'une manière qui
puisse me satisfaire à 100%.
> J'espère aussi ne pas avoir était trop rude, c'est la fatigue qui commence à se sentir :-)
Non, non, je n'ai absolument pas ressenti ça dans ta réponse. Pas
de souci. Merci de ton aide.
--
François Lafont
Reply to: