Ho parlato con alcuni manutentori del canale IRC Debian irc: //irc.debian.org#debian-mentors , chiedendo esattamente la stessa cosa, e il consenso generale è stato:
Soluzione n. 1:
L'integrazione delle dipendenze nel pacchetto copiando i loro file di origine come una singola base di codice è molto disapprovata. Avrebbe vanificato lo scopo di un sistema di packaging che gestisse dipendenze, aggiornamenti, versioning, ecc.
Soluzione n. 3:
Scaricare pacchetti non debian al volo quando si installa un binario ( .deb) è un grave rischio per la sicurezza, sicuramente un no-no. Non saresti nemmeno in grado di ispezionare le dipendenze estraendo il deb, perché vengono scaricati e installati al momento dell'installazione. È un approccio che ignora completamente il sistema di repository. Nessun utente interessato sarebbe contento di un pacchetto che, dietro le quinte (e come root, ricorda!), Scarica software aggiuntivo non attendibile da fonti non attendibili. Sì, ciò richiederebbe di armeggiare con DEBIAN/postinst(o preinst) ed emettere un wget(o, nel tuo caso,pip install), e questo è l'approccio adottato da Flash, Oracle Java, Steam e altri. Ma questo è un software proprietario, a codice chiuso, quindi la loro sicurezza non è comunque nulla.
Soluzione n. 1.5:
Lei non ha menzionato, ma è possibile integrare le dipendenze solo in fase di compilazione , vale a dire, nella fonte del pacchetto (il .orig.tar.gz, .debian.tar.gz, .dsctriade), scaricando da Cheese Shop quando si crea il pacchetto "binario" (la .deb). Le istruzioni per pip installdovrebbero andare in debian/rules(notare la minuscola debian, al contrario del pacchetto binario), e verrebbero eseguite quando si emette debuildo dpkg-buildpackage.
Questa è una via di mezzo tra # 1 e # 3. Riduce (ma non risolve!) Alcuni dei problemi di # 3: almeno è possibile ispezionare il prodotto finale e .debnon richiederebbe l'accesso a Internet al momento dell'installazione. Tutti i rischi e gli oneri sono trasferiti dall'utente finale al manutentore del pacchetto. Tuttavia, presenta gli stessi problemi del n. 1, in quanto ignora la maggior parte dell'infrastruttura del sistema di imballaggio. Dopotutto, gestire le dipendenze (versioni, aggiornamenti, requisiti, conflitti) è il motivo per cui dpkg/ è aptstato creato in primo luogo! :)
Soluzione n. 2:
The One True Right Way ™ . Crei pacchetti debian per le tue dipendenze, li elenchi come requisiti nel pacchetto e spedisci tutti i .debspacchetti o sorgente.
Da lì, hai una serie di opzioni:
Invia i pacchetti sorgente, sia il tuo software che le sue dipendenze, per l'inclusione a Debian. Se accettati, sarebbero automaticamente disponibili per tutti gli utenti Debian, inclusi tutti i derivati come Ubuntu.
Carica i pacchetti sorgente su Launchpad , creando così un PPA che qualsiasi utente Ubuntu (e suoi derivati come Linux Mint) potrebbe facilmente aggiungere e installare
Ospita il tuo repository debian nel tuo sito Web, che gli utenti di qualsiasi sistema basato su Debian potrebbero aggiungere al loro /etc/apt/sources.list.de utilizzare l' aptinfrastruttura per scaricare, installare e mantenere aggiornati (come sopra!)
Ospita i .debfile per il download diretto e l'installazione. No apto aggiornamenti automatici coinvolti pensato.
Per quanto riguarda come impacchettare le tue dipendenze PyPi (e anche il tuo software Python!), Ci sono una serie di strumenti e riferimenti che semplificano il processo:
stdeb , come hai detto. Vecchio e buono.
Pybuild , un nuovo, straordinario strumento di Debian che sostituisce stdeb.
E molti riferimenti utili:
Ho bisogno di aiuto? Dai un'occhiata a quelli: