J'ai parlé à quelques responsables du canal Debian IRC irc: //irc.debian.org#debian-mentors , demandant exactement la même chose, et le consensus général était:
Solution n ° 1:
L'intégration des dépendances dans votre package en copiant leurs fichiers source comme une base de code unique est très mal vue. Cela irait à l'encontre de l'objectif d'un système d'emballage qui gère les dépendances, les mises à jour, la gestion des versions, etc.
Solution n ° 3:
Le téléchargement à la volée de paquets non Debian lors de l'installation d'un binaire ( .deb) est un sérieux risque de sécurité, certainement un non-non. Vous ne pourriez même pas inspecter les dépendances en extrayant le deb, car elles sont téléchargées et installées au moment de l'installation. C'est une approche qui contourne complètement le système des référentiels. Aucun utilisateur concerné ne serait satisfait d'un package qui, en coulisse (et comme root, rappelez-vous!), Télécharge des logiciels non fiables supplémentaires à partir de sources non fiables. Oui, cela nécessiterait de jouer avec DEBIAN/postinst(ou preinst) et d'émettre un wget(ou, dans votre cas,pip install), et c'est l'approche adoptée par Flash, Oracle Java, Steam et autres. Mais il s'agit d'un logiciel propriétaire et fermé, leur sécurité n'est donc pas de toute façon.
Solution # 1.5:
Vous ne l' avez pas mentionné, mais vous pouvez intégrer les dépendances uniquement au moment de la construction , par exemple, dans la source de paquet (la .orig.tar.gz, .debian.tar.gz, .dsctriade), par téléchargement à partir PyPI lors de la création du paquet « binaire » (le .deb). Les instructions pour le pip installentreraient dans debian/rules(notez les minuscules debian, par opposition au paquet binaire), et seraient exécutées lorsque vous émettez debuildou dpkg-buildpackage.
Il s'agit d'un juste milieu entre # 1 et # 3. Il atténue (mais ne résout pas!) Certains des problèmes du n ° 3: au moins, vous pouvez inspecter le produit final et .debne nécessiterait pas d'accès Internet au moment de l'installation. Tous les risques et charges sont transférés de l'utilisateur final au responsable de l'emballage. Mais, a les mêmes problèmes que # 1, car il contourne la plupart de l'infrastructure du système d'emballage. Après tout, la gestion des dépendances (versions, mises à jour, exigences, conflits) est la raison pour laquelle dpkg/ a aptété créé en premier lieu! :)
Solution n ° 2:
The One True Right Way ™ . Vous créez des packages Debian pour vos dépendances, les listez comme exigences dans votre package et expédiez tous les .debspackages source.
De là, vous avez un certain nombre d'options:
Soumettez les paquets source, à la fois votre logiciel et ses dépendances, pour inclusion dans Debian. S'ils étaient acceptés, ils seraient automatiquement disponibles pour tous les utilisateurs de Debian, y compris tous les dérivés comme Ubuntu.
Téléchargez les packages source sur Launchpad , créant ainsi un PPA que tout utilisateur d'Ubuntu (et ses dérivés comme Linux Mint) pourrait facilement ajouter et installer
Hébergez votre propre référentiel Debian sur votre site Web, que les utilisateurs de n'importe quel système basé sur Debian pourraient ajouter à leur /etc/apt/sources.list.det utiliser l' aptinfrastructure pour télécharger, installer et maintenir à jour (comme ci-dessus!)
Hébergez les .debfichiers pour téléchargement direct et installation. Aucune aptmise à jour ou mise à jour automatique impliquait une réflexion.
Quant à la façon de conditionner vos dépendances PyPi (et votre logiciel python aussi!), Il existe un certain nombre d'outils et de références qui facilitent le processus:
stdeb , comme vous l'avez mentionné. Oldie et goodie.
Pybuild , un nouvel outil incroyable de Debian qui remplace stdeb.
Et de nombreuses références utiles:
Besoin d'aide? Découvrez-les: