He hablado con algunos mantenedores en el canal IRC de Debian irc: //irc.debian.org#debian-mentors , preguntando exactamente lo mismo, y el consenso general fue:
Solución # 1:
Integrar dependencias en su paquete copiando sus archivos de origen como una única base de código está muy mal visto. Derrotaría el propósito de un sistema de empaque que maneje dependencias, actualizaciones, versiones, etc.
Solución # 3:
La descarga de paquetes que no son de Debian sobre la marcha al instalar un binario ( .deb) es un grave riesgo de seguridad, definitivamente un no-no. Ni siquiera podría inspeccionar las dependencias extrayendo deb, porque se descargan e instalan en el momento de la instalación. Es un enfoque que omite completamente el sistema de repositorios. Ningún usuario preocupado estaría contento con un paquete que, detrás de escena (y como root, recuerde), descarga software adicional no confiable de fuentes no confiables. Sí, eso requeriría jugar con DEBIAN/postinst(o preinst) y emitir un wget(o, en su caso,pip install), y ese es el enfoque adoptado por Flash, Oracle Java, Steam y otros. Pero ese es un software patentado de código cerrado, por lo que su seguridad no es nada de todos modos.
Solución # 1.5:
Usted no ha mencionado, pero se podría integrar las dependencias sólo al tiempo de construcción , es decir, en el origen del paquete (el .orig.tar.gz, .debian.tar.gz, .dsctriada), mediante la descarga de PyPi al crear el paquete "binario" (el .deb). Las instrucciones para pip installentrarían en debian/rules(observe las minúsculas debian, en oposición al paquete binario), y se ejecutarían cuando emita debuildo dpkg-buildpackage.
Este es un término medio entre # 1 y # 3. Mitiga (¡pero no resuelve!) Algunos de los problemas del n. ° 3: al menos puede inspeccionar el producto final y .debno requeriría acceso a Internet en el momento de la instalación. Todos los riesgos y las cargas se transfieren del usuario final al mantenedor del paquete. Pero tiene los mismos problemas que el n. ° 1, ya que omite la mayor parte de la infraestructura del sistema de empaque. Después de todo, el manejo de dependencias (versiones, actualizaciones, requisitos, conflictos) es la razón dpkgpor la cual / aptfue creado en primer lugar. :)
Solución # 2:
The One True Right Way ™ . Puede crear paquetes de Debian para sus dependencias, enumerarlos como requisitos en su paquete y enviar todos los .debspaquetes de origen.
A partir de ahí, tiene una serie de opciones:
Envíe los paquetes fuente, tanto su software como sus dependencias, para incluirlos en Debian. Si se aceptan, estarán disponibles automáticamente para todos los usuarios de Debian, incluidos todos los derivados como Ubuntu.
Cargue los paquetes fuente en Launchpad , creando así un PPA que cualquier usuario de Ubuntu (y sus derivados como Linux Mint) podría agregar e instalar fácilmente
Hospede su propio repositorio de Debian en su sitio web, que los usuarios de cualquier sistema basado en Debian puedan agregar a ellos /etc/apt/sources.list.dy usar la aptinfraestructura para descargar, instalar y mantenerse actualizado (¡como lo anterior!)
Aloje los .debarchivos para descarga directa e instalación. Ninguna apto actualizaciones automáticas involucraban pensamiento.
En cuanto a cómo empaquetar sus dependencias PyPi (¡y su software python también!), Hay una serie de herramientas y referencias que facilitan el proceso:
stdeb , como mencionaste. Oldie y goodie.
Pybuild , una nueva y sorprendente herramienta de Debian que reemplaza stdeb.
Y muchas referencias útiles:
¿Necesitas ayuda? Mira eso: