Dipendenze Build in Runtime in Nix

Question

Sto appena iniziando a familiarizzare con Nix, quindi mi scuso se ho perso la risposta alla mia domanda nei documenti.

Desidero utilizzare Nix per configurare una macchina di produzione sicura con il set minimo di librerie ed eseguibili. Non voglio alcun compilatore o altri strumenti di sviluppo presenti perché questi possono essere rischi per la sicurezza.

Quando installo alcuni pacchetti, sembra che dipendano solo dall'insieme minimo di dipendenze di runtime. Ad esempio, se installo apache-tomcat-8.0.23, ottengo un runtime Java (JRE) e i file JAR predefiniti che comprendono Tomcat.

D'altra parte, alcuni pacchetti sembrano includere una toolchain di compilazione completa come dipendenze. Prendendo un altro esempio basato su Java, quando installo spark-1.4.0 Nix tira giù il kit di sviluppo Java (JDK), che comprende un compilatore, e tira anche l'Maven strumento di costruire ecc

Quindi, le mie domande sono le seguenti:

1. I pacchetti Nix distinguono tra dipendenze di build e di runtime?
2. Perché alcuni pacchetti sembrano dipendere dagli strumenti di compilazione mentre altri richiedono solo il runtime? Tutto dipende da come l'autore del pacchetto ha concluso l'applicazione?
3. Se un pacchetto contiene dipendenze di build che non desidero, c'è qualcosa che io, come l'operatore, posso fare al riguardo, tranne progettare il mio packaging alternativo per la stessa applicazione?

Molte grazie.

Answer 1

1. Le dipendenze runtime sono un sottoinsieme delle dipendenze accumulo temporali che Nix determina automaticamente scansionando l'uscita generato per la parte hash del percorso memorizzare ogni accumulo tempo dipendenze. Ad esempio, se si crea un pacchetto utilizzando il compilatore /nix/store/abcdef...-foo-1.20, Nix sottoporrà a scansione tutti i file nell'output generato per il bit hash abcdef.... Se si trova questo hash, si presume che l'output faccia riferimento al compilatore in qualche modo, quindi è kepts come una dipendenza di runtime. Se questo hash non si verifica, tuttavia, l'output generato non ha alcun riferimento al compilatore e pertanto non può accedervi in ​​fase di runtime, pertanto foo-1.20 viene considerato come dipendenza solo in fase di sviluppo.

2. Alcuni pacchetti registrano ampie parti del proprio ambiente di costruzione a scopo informativo/di debug. Perl, ad esempio, memorizza ogni piccolo dettaglio sugli strumenti utilizzati per compilarlo, quindi tutti questi percorsi di archivio finiscono per essere trattati come dipendenze di runtime, nonostante il fatto che Perl non ne abbia effettivamente bisogno in fase di runtime, ma Nix non può sapere: semplicemente sa che il percorso del negozio Perl fa riferimento a quegli strumenti. Ora, i manutentori di Nixpkgs di solito si impegnano a ripulirlo, cioè eliminando il file di log che contiene tutti quei percorsi del negozio dall'installazione, ecc., Ma di sicuro ci sono ancora molti pacchetti nel database che non sono ancora stati ottimizzati per quella fine ancora.

3. Supponiamo che ti piacerebbe compilare una versione di openssh che non dipenda da PAM. Quindi è possibile rimuovere l'input di build dall'espressione per mezzo di un override, ovvero sostituire l'argomento pam che viene normalmente passato alla funzione di creazione openssh con null.Per fare questo, memorizzare il file seguente in ~/.nixpkgs/config.nix

   { 
       packageOverrides = super: let self = super.pkgs; in { 
       openssh-without-pam = super.openssh.override { 
        pam = null; 
       }; 
       }; 
   } 
   

   e ora installare il pacchetto eseguendo:

   $ nix-env -f "<nixpkgs>" -iA openssh-without-pam