Perché i makefile dovrebbero avere un obiettivo di "installazione"?

Molti script build o Makefile hanno una destinazione di installazione perché sono stati creati prima dell'esistenza di gestori di pacchetti e perché ancora oggi molti sistemi non hanno gestori di pacchetti. Inoltre, ci sono sistemi in cui make install in realtà è il modo preferito di gestire i pacchetti.

Un makefile potrebbe non avere install target e, cosa più importante, puoi avere programmi che non dovrebbero nemmeno essere installabili (ad esempio perché dovrebbero essere eseguiti dalla loro directory di build, o perché possono essere installati ovunque) . Il target install è solo una convenzione per il solito makefile -s.

Tuttavia, molti programmi richiedono l'esecuzione di risorse esterne (ad esempio: font, database, file di configurazione, ecc.). E il loro eseguibile spesso fa delle ipotesi su queste risorse. Ad esempio, la tua shell bash leggerà generalmente un file di inizializzazione da /etc/bash.bashrc etc .... Queste risorse sono generalmente nel file system (vedi hier (7) per le convenzioni sulla gerarchia dei file) e il percorso file predefinito è incorporato nell'eseguibile.

Prova ad usare stringhe (1) sulla maggior parte dei file eseguibili del tuo sistema. Scoprirai quali percorsi di file sono noti.

BTW, per molti programmi GNU che usano autoconf , potresti eseguire make install DESTDIR=/tmp/destdir/ senza essere root. Quindi /tmp/destdir/ viene riempito con i file che devono essere successivamente confezionati.

FWIW, tendo a credere che il mio bismon (licenza GPLv3 +) (descritto nel mio bismon-chariot-doc.pdf rapporto) non può essere" installato "; Non sono sicuro di poterlo provare, e non riesco a immaginare come posso rendere il programma installabile.

Ci sono diversi motivi che mi vengono in mente.

• Molti pacchetti di software per la creazione - il sistema di build Debian per esempio, e IIRC rpm - già si aspettano dall'edificio script per "installare" il programma in una sottodirectory speciale. Quindi è guidato dalla compatibilità con le versioni precedenti in entrambe le direzioni.
• Un utente potrebbe voler installare il software in uno spazio locale, come nella directory $HOME . Non tutti i gestori di pacchetti lo supportano.
• Potrebbero esserci ancora ambienti privi di pacchetti.

Una ragione non menzionata è che ci sono molte volte quando non si utilizza la versione corrente del software o si utilizza una versione modificata del software. Cercando di creare un pacchetto personalizzato non è solo più lavoro, ma può entrare in conflitto con i pacchetti attualmente creati e distribuiti. Nel codice open source questo accade molto soprattutto se vengono introdotte modifiche di rottura nelle versioni future che si stanno utilizzando.

Supponiamo che tu stia utilizzando il progetto open source FOO che è attualmente in versione 2.0.1 e stai utilizzando la versione 1.3.0. Non si vuole usare nulla sopra questo perché la versione 2.0.0 non è compatibile con ciò che si sta facendo attualmente, ma c'è una singola correzione di bug in 2.0.1 di cui hai disperatamente bisogno. Avendo l'opzione make install , ti consigliamo di installare il software 1.3.0 modificato senza doversi preoccupare di creare un pacchetto e installarlo sul tuo sistema.

Le distribuzioni Linux in genere separano la manutenzione del programma dalla manutenzione dei pacchetti. Un sistema di compilazione che integri la generazione dei pacchetti costringerebbe i manutentori dei programmi a eseguire anche la manutenzione dei pacchetti.

Questa è solitamente una cattiva idea. Le distribuzioni dispongono di numerose infrastrutture per verificare la coerenza interna, fornire binari per più piattaforme di destinazione, eseguire piccole modifiche per integrarsi meglio con il resto del sistema e fornire un'esperienza coerente agli utenti che segnalano bug.

Per generare pacchetti direttamente da un sistema di generazione, devi integrare o ignorare tutta questa infrastruttura. Integrarlo sarebbe un sacco di lavoro per un beneficio discutibile, e scavalcarlo darebbe un'esperienza utente peggiore.

Questo è uno dei problemi "top della catena alimentare" tipici dei sistemi multipartitici. Se si dispone di più sistemi complessi, è necessario disporre di una gerarchia chiara di quale sistema sia responsabile del coordinamento di tutti gli altri.

Nel caso della gestione dell'installazione del software, il gestore dei pacchetti è questo componente, che eseguirà il sistema di compilazione del pacchetto, quindi porterà l'output attraverso una comoda interfaccia ("file in una directory dopo un passo di installazione"), genererà un pacchetto e prepararlo per il caricamento su un repository.

Il gestore pacchetti si trova nel mezzo tra il sistema di compilazione e il repository qui, ed è nella posizione migliore per integrarsi bene con entrambi.

Potresti aver notato che ci sono solo pochi dei pacchetti JavaScript disponibili attraverso npm disponibili anche attraverso apt - questo è principalmente dovuto al fatto che le persone JavaScript hanno deciso che npm e il repository associato sarebbero stati i migliori della loro catena alimentare, che ha reso quasi impossibile spedire questi pacchetti come pacchetti Debian.

Con il mio cappello Debian Developer su: se rilasci software open source, lascia la confezione ai manutentori della distribuzione. Risparmia sia te che noi un sacco di lavoro.

Bene, gli sviluppatori di applicazioni sono quelli che sanno dove dovrebbe andare ogni file. Potrebbero lasciarlo nella documentazione, e i manutentori dei pacchetti leggerlo e creare uno script per ogni pacchetto. Forse i manutentori del pacchetto interpreteranno male la documentazione e dovranno eseguire il debug dello script fino a quando non funzionerà. Questo è inefficiente. È meglio che lo sviluppatore dell'applicazione scriva uno script per installare correttamente l'applicazione che ha scritto.

Poteva scrivere uno script di installazione con un nome arbitrario o magari renderlo parte della procedura di qualche altro script. Tuttavia, avendo un comando di installazione standard, make install (una convenzione che precede i gestori di pacchetti), è diventato davvero facile creare pacchetti. Se osservi il modello PKGBUILD per creare pacchetti Archlinux , puoi vedere che la funzione che in realtà pacchetti semplicemente fa un make DESTDIR="$pkgdir/" install . Questo probabilmente funziona per la maggior parte dei pacchetti e probabilmente di più con una piccola modifica. Grazie al fatto che make (e gli autotools) sono standard, la confezione è davvero molto semplice.