Tenere traccia dei programmi

Quando installo un semplice programma, spesso lo usa make && make installe spesso non ha nemmeno una destinazione di disinstallazione .

Se desidero aggiornare un programma, è un protocollo standard supporre che riscriva senza problemi sul vecchio programma?

Come posso tenere traccia di questi programmi; la maggior parte delle persone semplicemente "spara e dimentica" e se non viene fornita alcuna destinazione di disinstallazione devo eliminare manualmente tutto?

Installa ogni programma in un albero di directory dedicato e usa Stow o XStow per far apparire tutti i programmi in una gerarchia comune. Stow crea collegamenti simbolici dalla directory specifica del programma a un albero comune.

Più in dettaglio, selezionare una directory di livello superiore, ad esempio /usr/local/stow. Installa ciascun programma sotto /usr/local/stow/PROGRAM_NAME. Ad esempio, organizza l'installazione dei suoi eseguibili /usr/local/stow/PROGRAM_NAME/bin, le sue pagine man /usr/local/stow/man/man1e così via. Se il programma utilizza autoconf, quindi esegui ./configure --prefix /usr/local/stow/PROGRAM_NAME. Dopo aver eseguito make install, esegui stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

E ora avrai collegamenti simbolici come questi:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Puoi facilmente tenere traccia di quali programmi hai installato elencando il contenuto della stowdirectory e sai sempre a quale programma appartiene un file perché è un collegamento simbolico a una posizione nella directory di quel programma. Disinstallare un programma eseguendo, stow -D PROGRAM_NAMEquindi eliminando la directory del programma. È possibile rendere temporaneamente non disponibile un programma eseguendolo stow -D PROGRAM_NAME(eseguire stow PROGRAM_NAMEper renderlo nuovamente disponibile).

Se si desidera poter passare rapidamente da una versione all'altra dello stesso programma, utilizzare /usr/local/stow/PROGRAM_NAME-VERSIONcome directory del programma. Per eseguire l'aggiornamento dalla versione 3 alla versione 4, installare la versione 4, quindi eseguire stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Le versioni precedenti di Stow non vanno molto oltre le basi che ho descritto in questa risposta. Le versioni più recenti, così come XStow (che non è stato mantenuto di recente) hanno funzionalità più avanzate, come la possibilità di ignorare determinati file man -> share/man, gestire meglio i collegamenti simbolici esistenti al di fuori della directory stow (come ), gestire automaticamente alcuni conflitti (quando due i programmi forniscono lo stesso file), ecc.

Se non si dispone o non si desidera utilizzare l'accesso root, è possibile selezionare una directory nella directory principale, ad es ~/software/stow. In questo caso, aggiungi ~/software/binal tuo PATH. Se mannon trova automaticamente le pagine man, aggiungile ~/software/manalle tue MANPATH. Aggiungi ~/software/infoa tuo INFOPATH, ~/software/lib/pythona tuo PYTHONPATHe così via come applicabile.

È possibile utilizzare checkinstall per creare un pacchetto (pacchetti compatibili con RPM, Deb o Slackware) In questo modo, è possibile utilizzare il gestore pacchetti distro per aggiungere / rimuovere l'applicazione (ma non aggiornare)

Si usa checkinstallal posto del make installcomando (usando il parametro -D per Deb; -R è RPM e -S è Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall costruirà e installerà il pacchetto per impostazione predefinita, oppure è possibile crearlo solo senza l'installazione.

checkinstall è disponibile nella maggior parte dei repository distro.

Per la maggior parte questo era il motivo dietro pacchetti, porte e altri tipi di gestori per impedire che accadesse questo tipo di cose.

Direi che la cancellazione manuale è l'unico modo per un'installazione manuale, a meno che qualcun altro abbia una risposta migliore a quel punto di cui potrei non essere a conoscenza.

Un'altra alternativa è dai suggerimenti di Linux From Scratch :

Maggiore controllo e gestione dei pacchetti utilizzando gli utenti dei pacchetti

3 Utenti del pacchetto
3.1 Introduzione

L'idea di base di questo schema è facilmente spiegabile. Ogni pacchetto appartiene a un determinato "utente del pacchetto". Quando si installa un pacchetto, lo si crea e si installa come questo utente del pacchetto, facendo sì che tutti i file installati appartengano all'utente del pacchetto. Di conseguenza, tutti i consueti compiti di gestione dei pacchetti possono essere comodamente raggiunti attraverso l'uso di utility standard da riga di comando. Un semplice ls -l <file>ti dirà, ad esempio, a quale pacchetto <file>appartiene e un find -user ...comando ti consente di eseguire un'operazione su tutti i file appartenenti a un determinato pacchetto, ad esempio eliminarli per disinstallare il pacchetto.

Ma la gestione dei pacchetti non è tutto ciò per cui gli utenti dei pacchetti sono adatti. Poiché gli utenti dei pacchetti non dispongono dei diritti di root, l'installazione di un pacchetto è limitata in ciò che può fare. Una cosa che un utente del pacchetto non è autorizzato a fare, ad esempio, è sovrascrivere i file da un altro utente del pacchetto. Gli scontri tra pacchetti diversi che desiderano installare un file binario, di libreria o di intestazione con lo stesso nome sono più comuni di quanto si possa pensare. Con gli utenti del pacchetto non corri mai il rischio che l'installazione del pacchetto B distrugga i file dal pacchetto A in silenzio senza che te ne accorga. Ogni tentativo di eseguire questa operazione durante l'installazione del pacchetto B provocherà un errore "Autorizzazione negata" o "Operazione non consentita" in modo da avere la possibilità di adottare le misure appropriate. Un'altra cosa che gli utenti del pacchetto non sono autorizzati a fare è installare i binari root setuid. La decisione di creare una radice setuid binaria è anche qualcosa che un amministratore prudente non vuole lasciare al creatore di un pacchetto software.

Di solito gli account utente del pacchetto non hanno una password valida, in modo che solo l'utente root possa su accedere a un utente del pacchetto, il che garantisce che gli utenti del pacchetto non si aprano ulteriormente nel sistema e minino la sicurezza. Tuttavia, è possibile impostare le password in modo da consentire a un coamministratore che si desidera sia in grado di installare e mantenere determinati pacchetti software per farlo senza avere accesso all'account root effettivo. Questo coamministratore potrebbe ad esempio installare, eliminare, modificare librerie aggiuntive che potrebbero essere necessarie per il suo gruppo di lavoro. Tuttavia, non sarebbe in grado di rimuovere o modificare librerie che non gli appartengono, come libc.

Dopo questo primo suggerimento, ho trovato una variante evoluta:

crablfs - Sistema di gestione dei pacchetti basato sull'utente

Questo crablfsè l'ultimo esempio di gestione dei pacchetti che usa uid e gid unici per la gestione dei pacchetti, ma su sourceforge si sta evolvendo di nuovo in ulfs:

uLFS: il tuo Linux gestibile e riutilizzabile da zero

Per gli utenti causali di pacchetti installati, penso che la soluzione LFS "utenti pacchetto" sia leggera, meno invasiva ed elegante. In breve, installi i pacchetti /usr/localo /home/user/localsegui i file usando uid e gid unici per ogni pacchetto, ma metti tutti i file nei luoghi tradizionali, nelle directory comuni /usr/local/bin, /usr/local/libcome in tutte le principali distribuzioni Linux ... occlusione dei file e sovrascrittura o eliminazione dei file indesiderati è evitato da un trucco Linux chiaro spiegato da Matthias S. Benkmann in more_control_and_pkg_man.txt che richiede solo la normale manipolazione dei permessi di file e directory, ad esempio il permesso di bit appiccicoso per le directory per evitare sovrascritture di file indesiderate:

3.3 Gruppi

Ogni utente del pacchetto appartiene ad almeno 2 gruppi. Uno di questi gruppi è il gruppo "installa", a cui appartengono tutti gli utenti del pacchetto (e solo gli utenti del pacchetto). Tutte le directory in cui i pacchetti possono installare elementi appartengono al gruppo di installazione. Questo include directory come / bin e / usr / bin ma esclude directory come / root o /. Le directory di proprietà del gruppo di installazione sono sempre scrivibili in gruppo. Questo sarebbe sufficiente per gli aspetti di gestione dei pacchetti, ma senza ulteriore preparazione questo non darebbe maggiore sicurezza o controllo perché ogni pacchetto potrebbe sostituire i file da un pacchetto diverso (la modifica sarebbe visibile nell'output dals -l, anche se). Per questo motivo tutte le directory di installazione ottengono l'attributo sticky. Ciò consente agli utenti di creare nuovi file ed eliminare o modificare i propri file nella directory, ma i file di altri utenti non possono essere modificati o rimossi. Nel resto di questo suggerimento, ogni volta che viene usato il termine "directory di installazione", si riferisce a una directory che appartiene all'installazione di gruppo, è scrivibile dal gruppo e appiccicosa. IOW, per trasformarti <dir>in una directory di installazione che faresti

chgrp installa && chmod g + w, o + t

Per me sembra una soluzione semplice e intelligente! Ho usato questo schema nella mia build LFS ed è una soluzione funzionante ...

1. È possibile creare un RPM vuoto come promemoria.
2. Puoi cercare di avvolgere correttamente il software in un RPM.
3. Puoi lasciare una copia dei tarfile dall'installazione /usr/src/non-rpmsper ricordarti (è quello che faccio di solito).