Pagina 1 di 1

Rimozione pacchetti orfani

Inviato: dom 4 nov 2007, 0:31
da Smjert
C'è qualche tool che fa ciò?
Perchè ho erroneamente installato troppo e alcuni pacchetti li tolto singolarmente sapendo dal nome che nn mi servono... ma le librerie se non sono usate sarebbe meglio trinciarle.

Inviato: dom 4 nov 2007, 1:20
da gallows
Avevo scritto tale slackorphan ma non riesco a trovarlo O_O
Quando, e se, lo trovo te lo linko.

Inviato: dom 4 nov 2007, 11:21
da submax82
Tracepkg del nostro absinthe ;)

Inviato: dom 4 nov 2007, 13:45
da Smjert
Giusto, ma rimuove solo i pacchetti che ho scaricato con quel tool, oppure fa anche una ricerca sul pc per vedere quali pacchetti può levare?
Cioè se ho installato un pacchetto con un altro tool non ha creato quel file delle dipendenze, è possibile comunque rimuoverle con Tracepkg o bisognava installare il pacchetto con quest'ultimo?

Inviato: dom 4 nov 2007, 13:59
da absinthe
allora: per rendere i set dei pacchetti installati consistente con tracepkg, devi lanciare prima un tracepkg --sync che risincronizza il database delle dipendenze con tutti i pacchetti installati.
detto questo la gestione degli orfani l'avevo iniziata ma poi l'ho rimossa dalla versione stabile perchè non trovavo il modo di renderla statisticamente sicura (evitare i falsi positivi più che altro) quindi temo che tracepkg non faccia quello che richiedi....

piuttosto puoi usarlo al rovescio... ma è una lagna imho: se credi che un tgz di una libreria sia inutilizzato, dopo aver sincronizzato il database dai un

Codice: Seleziona tutto

tracepkg -s /var/log/packages/libreria.tgz 
e lui poi ti dice se quel pacchetto è utilizzato da qualcuno! ad ogni modo se dai una cosa del tipo:

Codice: Seleziona tutto

tracepkg -s /var/log/packages/* > search.log
ottieni l'elenco di tutti i tgz con la lista dei pacchetti che li utilizzano. se un pacchetto non è utilizzato da nessuno e NON è un applicativo end user, potrebbe essere rimuovibile (forse, può darsi, magari, con un certo grado di verità, forse che sì forse che no :-)

occhio che certi pacchetti no risultano utilizzati ma invece lo sono! ad esempio alcune dipendenze di octave non risultano dall'analisi eseguita con ldd ma servono al funzionamento del tool! viceversa ad esempio ci sono alcuni "ordigni" come mysql che risultano come dipendenze di kde ma che in realtà sono puramente accessori, tanto è vero che kde funziona anche senza mysql!

io starei attento alla rimozione automatica degli orfani perchè non è così banale! e più che altro aspetterei il tool di gallows che poi lo schiaffo dentro a tracepkg se è rilasciato con licenza gpl2 :badgrin:

per assurdo è sempre molto comodo fare l'opposto di quello che hai fatto tu: installare di tutto e di più e poi rimuoverlo con tanto di dipendenze non condivise con altri applicativi! troncare la base di un albero di dipendenze è un pò nocivo! prova ad esempio ad installare tutto l'albero delle dipendenze di mplayer e poi, rimosso mplayer a capire cosa rimane orfano... :-/ c'è da impazzirci...

M

Inviato: dom 4 nov 2007, 14:43
da Smjert
Beh io alla fine ho installato di tutto e di più.. volevo fare l'upgrade alla current e ho interpretato male la guida Upgrade.txt (solo io ce la posso fare .) e ho preso la directory dei pacchetti dal cdrom 12.0 nn quella online, quindi mi sono installato tutti i pacchetti possibili e imagginabili :|
Ora volevo fare un po' di pulizia...
per assurdo è sempre molto comodo fare l'opposto di quello che hai fatto tu: installare di tutto e di più e poi rimuoverlo con tanto di dipendenze non condivise con altri applicativi!
Quali altri applicativi?
Cioè tu dici di usare quindi un programma che gestisca le dipendenze dandogli come pacchetto da rimuovere quello principale, in modo che tolga poi tutto il resto invece di cancellare solo il pacchetto principale e poi andarsi a pescare quello che si era tirato dietro nell'installazione giusto?

Ma da quanto mi dici magari una libreria segnalata nelle dipendenze del pacchetto che voglio rimuovere è utilizzata anche da un altro programma, che però non lo dice esplicitamente, e che quindi se vado a rimuovere il pacchetto con un programma che gestisce le dipendenze me la va a togliere e poi l'altro prog si incappera.
Come si risolve questa cosa? :P

Che casino .

Inviato: dom 4 nov 2007, 19:05
da absinthe
Smjert ha scritto:Beh io alla fine ho installato di tutto e di più.. volevo fare l'upgrade alla current e ho interpretato male la guida Upgrade.txt (solo io ce la posso fare .) e ho preso la directory dei pacchetti dal cdrom 12.0 nn quella online, quindi mi sono installato tutti i pacchetti possibili e imagginabili :|
Ora volevo fare un po' di pulizia...
per assurdo è sempre molto comodo fare l'opposto di quello che hai fatto tu: installare di tutto e di più e poi rimuoverlo con tanto di dipendenze non condivise con altri applicativi!
Quali altri applicativi?
Cioè tu dici di usare quindi un programma che gestisca le dipendenze dandogli come pacchetto da rimuovere quello principale, in modo che tolga poi tutto il resto invece di cancellare solo il pacchetto principale e poi andarsi a pescare quello che si era tirato dietro nell'installazione giusto?
giusto
Ma da quanto mi dici magari una libreria segnalata nelle dipendenze del pacchetto che voglio rimuovere è utilizzata anche da un altro programma, che però non lo dice esplicitamente, e che quindi se vado a rimuovere il pacchetto con un programma che gestisce le dipendenze me la va a togliere e poi l'altro prog si incappera.
Come si risolve questa cosa? :P

Che casino .
sì il problema sono appunto questi falsi positivi e falsi negativi che ogni tanto mandano a pallino i sistemi automatici! però si fanno sicuramente meno danni in quel modo e al più si reinstalla un tgz tolto per sbaglio!
in realtà slack non è progettata per queste cose quindi in teoria ogni sistema è sbagliato. ad ogni modo se la lista delle dipendenze è fatta a mano dal pacchettizatore i rischi sono bassi. tuttavia sorge il problema che trovare a mano le dipendenze è come spararsi in una mano... :-) quindi anche slapt-get in realtà utilizza file di dipendenze generati in semiautomatico con requiredbuilder. in questo caso però non dovrebbero esistere flasi negativi ma solo falsi positivi (che è un passo avanti). solo che slapt-get se ne impippa di rimuovere un tgz e tutte le dipendenze non condivise (o presunte tali) e quindi siamo punto e a capo :-)
io mi sono fatto tracepkg per sapere esattamente quello che faceva il codice (non sono bono a fare l'hacking di codice altrui...) e comunque faccio i miei errori!

M

Inviato: gio 8 nov 2007, 16:34
da Smjert
Ciao, ho scaricato il tuo programmino e ho provato a vedere il funzionamento del comando tracepkg -s /var/log/packages/* > search.log.
Non riesco però a interpretare bene il risultato poichè c'è una lista di pacchetti in colonna e basta :P, te ne riporto un pezzo.

Codice: Seleziona tutto

/var/log/packages/apr-util-1.2.8-i486-1
/var/log/packages/httpd-2.2.6-i486-1
/var/log/packages/kdesdk-3.5.8-i486-1
/var/log/packages/kdevelop-3.5.0-i486-1
/var/log/packages/subversion-1.4.4-i486-1
/var/log/packages/httpd-2.2.6-i486-1
/var/log/packages/kdesdk-3.5.8-i486-1
/var/log/packages/kdevelop-3.5.0-i486-1
/var/log/packages/subversion-1.4.4-i486-1
/var/log/packages/audacious-plugins-1.4.0dr1-i486-1ultra
/var/log/packages/k3b-1.0.3-i486-1
/var/log/packages/kdeaccessibility-3.5.8-i486-1
/var/log/packages/kdeaddons-3.5.8-i486-1
/var/log/packages/kdeartwork-3.5.8-i486-1
/var/log/packages/kdebase-3.5.8-i486-1
/var/log/packages/kdeedu-3.5.8-i486-1
/var/log/packages/kdegames-3.5.8-i486-1
/var/log/packages/kdelibs-3.5.8-i486-2
/var/log/packages/kdemultimedia-3.5.8-i486-1
/var/log/packages/kdenetwork-3.5.8-i486-1
/var/log/packages/kdepim-3.5.8-i486-1
/var/log/packages/koffice-1.6.3-i486-1
/var/log/packages/libao-0.8.8-i486-1

/var/log/packages/gtkspell-2.0.11-i486-1sl
/var/log/packages/kdelibs-3.5.8-i486-2
/var/log/packages/php-5.2.4-i486-1
/var/log/packages/xchat-2.8.4-i486-1sl
Come vedi ci sono anche degli spazi tra un blocco e l'altro... questo vuol dire che il pacchetto che sta in cima (al blocco) è quello principale e quelli sotto sono i pacchetti che dipendono dal primo?

Inviato: ven 9 nov 2007, 10:48
da absinthe
ma porc! già me ne sono dimenticato... ops :oops: da qualche versione a questa parte produco un mero elenco e non una roba intestata del tipo: i seguenti pacchetti dipendono dal pacchetto X. scus! comunque sia puoi lanciare sto script:

Codice: Seleziona tutto

echo --- > search.log
for file in /var/log/packages/*; do
echo i seguenti pacchetti dipendono da $file:
tracepkg -s /var/log/packages/$file
echo ---
done >> search.log
ti crea una lista "leggibile" anche se processi in batch tutto il tuo set di pacchetti. a titolo di esempio ti posto uno stralcio dell'output di cat search.log:
---
i seguenti pacchetti dipendono da /var/log/packages/aaa_terminfo-5.6-noarch-1:

/var/log/packages/aaa_terminfo-5.6-noarch-1
is a "noarch" package, it hasn't any dependency and can't be detected as dependency
---
i seguenti pacchetti dipendono da /var/log/packages/aalib-1.4rc5-i486-2:
/var/log/packages/gimp-2.2.17-i486-1_slack12.0
/var/log/packages/mplayer-1.0rc2-i686-1sl
---
i seguenti pacchetti dipendono da /var/log/packages/acct-6.3.2-i386-1:

---
nel primo caso ti fa notare che si tratta di un pacchetto "noarch" e quindi non ha dipendenze binarie ne può essere una dipendenza binaria (ma può essere qualsiasi altra cosa!), nel secondo caso ti dice che gimp e mplayer dipendono da aalib, nel terzo ti dice che _in apparenza_ niente dipende da acct. quindi se acct non è un applicativo end-user ma una libreria puoi toglierlo... responsabilità tua :-)

M