# Ripulire il sistema [sarà TIP?]

## Peach

Ciao gente

stavo pensando che nel mio piccolo sono proprio un pessimo amministratore di sistema  :Laughing: 

allora, ho pensato di fare una cosa molto semplice a dirsi ma nn a farsi:

Ripulire il sistema

come fare?

Allora personalmente ho iniziato ad usare due programmi che mi sembrano quasi indispensabili in queste situazioni:

etcat e qpkg

Pacchetti doppi

con entrambi posso vedere i dups dei pacchetti installati, alcuni volontariamente (vedi GIMP), altri a mia insaputa e di cui non so che fare... facciamo un esempio:

```
# etcat -v guile

[ Results for search key : guile ]

[ Applications found : 4 ]

*  dev-util/guile :

        [   ] dev-util/guile-1.4-r3 (1.4)

        [  I] dev-util/guile-1.4.1 (1.4.1)

        [   ] dev-util/guile-1.6.4 (12)

        [  I] dev-util/guile-1.6.4-r1 (12)
```

etcat --help per maggiori info

io ora mi chiedo che ci faccio con due versioni di guile installate?

proviamo allora a vedere le dipendenze?

Il pacco che trovo è che con:

```
# etcat -d guile
```

ti vengono fuori tutti i pacchetti di questo mondo anche quelli non installati e tutte le versioni e da qui l'output (troncato per comodità):

```
# etcat -d guile

[ Results for search key : guile ]

omissis

* media-sound/glame-0.6.3

  >=dev-util/guile-1.4-r3

* media-sound/glame-0.6.4

  >=dev-util/guile-1.4-r3

* media-sound/glame-1.0.1

  >=dev-util/guile-1.4-r3

* media-sound/lilypond-1.5.15

  >=dev-util/guile-1.4-r3

* media-sound/lilypond-1.6.6

  >=dev-util/guile-1.4-r3

* media-sound/lilypond-1.6.9

  >=dev-util/guile-1.4-r3

* media-sound/lilypond-1.8.2

  >=dev-util/guile-1.6.4

* media-sound/lilypond-2.0.0

  >=dev-util/guile-1.6.4

* media-sound/snd-6.7

  guile?

* media-video/sinek-0.7

  guile?

* net-dialup/penggy-0.2.1

  >=dev-util/guile-1.4.0

* net-mail/mailutils-0.3.1

  dev-util/guile

* net-mail/mailutils-0.3

  dev-util/guile

* x11-libs/guile-gtk-0.19-r1

  =dev-util/guile-1.4*

* x11-libs/guile-gtk-0.19

  =dev-util/guile-1.4*

* x11-libs/guile-gtk-1.2.0.31

  >=dev-util/guile-1.6
```

Ora però con qpkg posso fare una cosa simile, ma più selettiva solo sui pacchetti installati, vediamo come:

```
# qpkg -q -I guile

dev-util/guile-1.4.1 *

DEPENDED ON BY:

        swig-1.3.16

dev-util/guile-1.6.4-r1 *

DEPENDED ON BY:

        swig-1.3.16
```

al solito: man qpkg

dopo una sana grattatina alla testa e dopo aver assunto una espressione a mo' di punto di domanda, prendo e butto nel cesso la versione + vecchia di guile, la 1.4.1.

L'unico dubbio che mi rimane è: ma perchè non è stato tolto a suo tempo?

Pacchetti Inutili

Per i pacchetti inutili invece vi chiedo collaborazione... mica posso prendere tutto quello che ho installato e verificare che non dipenda da niente e non sia dipendenza di nessuno?!? o si?  :Laughing: 

da qui sarebbe comodo sapere:

1) come disinstallare un programma (noi sappiamo quale) senza lasciare moncherini di librerie inutilizzate in giro

pensavo a qualcosa tipo: dipendenze del programma, controllo singole dipendenze dirette (E la cosa si fa complessa quando sono un tot), e controllo sucessivo delle singole dipendenze dirette se dipendono o se sono richieste da altri programmi.

2) come disinstallare programmi o librerie che non sono state tolte in maniera oculata dal punto 1). qui invece mi mette paura dover controllare tutte le foglie dell'albero...  :Twisted Evil: 

----------

## Peach

tra l'altro facendo un po' di repulisti di pacchetti doppi m'è sparita la "services have circular dependecies.." che continuavo ad avere ad ogni "regenerating /etc/ld.so.cache"

 :Smile: 

----------

## Peach

help!!! mi sto perdendo in un bicchier d'acqua... effettivamente quanto detto sopra non è sbagliato anche se in certi versi incompleto:

ad esempio: di libgtkhtml DEVE essere installato in due versioni

```
# qpkg -q -I libgtkhtml

gnome-extra/libgtkhtml-3.0.9 *

DEPENDED ON BY:

        gnome-2.4

        yelp-2.4.0

        gimp-1.3.22

        evolution-1.4.5

gnome-extra/libgtkhtml-2.4.0 *

DEPENDED ON BY:

        gnome-2.4

        yelp-2.4.0

        gimp-1.3.22

        evolution-1.4.5
```

con

```
# etcat -d libgtkhtml

[ Results for search key : libgtkhtml ]

* app-office/gnotime-2.1.6

  >=gnome-extra/libgtkhtml-2.0

* dev-python/gnome-python-2.0.0

  =gnome-extra/libgtkhtml-2*

* dev-util/devhelp-0.6.0

  =gnome-extra/libgtkhtml-2*

* dev-util/devhelp-0.7

  =gnome-extra/libgtkhtml-2*

* gnome-extra/nautilus-gtkhtml-0.3.2

  =gnome-extra/libgtkhtml-2*

* gnome-extra/yelp-2.4.1

  =gnome-extra/libgtkhtml-2*

* gnome-extra/yelp-2.2.0

  =gnome-extra/libgtkhtml-2.2*

* gnome-extra/yelp-2.2.2

  =gnome-extra/libgtkhtml-2.2*

* gnome-extra/yelp-2.2.3

  =gnome-extra/libgtkhtml-2.2*

* gnome-extra/yelp-2.4.0

  =gnome-extra/libgtkhtml-2*

* media-gfx/gimp-1.3.21

  =gnome-extra/libgtkhtml-2*

* media-gfx/gimp-1.3.22

  =gnome-extra/libgtkhtml-2*

* net-mail/balsa-2.0.10

  =gnome-extra/libgtkhtml-2*

* net-mail/balsa-2.0.11

  =gnome-extra/libgtkhtml-2*

* net-mail/balsa-2.0.14

  =gnome-extra/libgtkhtml-2*

* net-mail/balsa-2.0.15

  =gnome-extra/libgtkhtml-2*

* net-mail/evolution-1.4.3

  >=gnome-extra/libgtkhtml-3.0.7

* net-mail/evolution-1.4.4

  >=gnome-extra/libgtkhtml-3.0.8

* net-mail/evolution-1.4.5

  >=gnome-extra/libgtkhtml-3.0.9

* net-misc/logjam-4.2.2

  >=gnome-extra/libgtkhtml-3.0

* net-misc/logjam-4.2.4

  >=gnome-extra/libgtkhtml-3.0

* net-www/screem-0.6.0

  =gnome-extra/libgtkhtml-2*

* net-www/screem-0.6.2

  =gnome-extra/libgtkhtml-2*

* net-www/screem-0.8.1

  =gnome-extra/libgtkhtml-2*
```

se nn erro (correct me pls) vedo per ciascuna versione dei pacchetti che dipendono da libgtkhtml che versione dello stesso vogliono. 

ovvero: evolution 1.4.5  vuole l'ultima versione, (3.0.9) mentre pacchetti come  gimp vogliono la versione 2*.

Ma, ancora, mi sbaglio o qpkg fa schifo?  :Twisted Evil:  perchè non mi scrive da chi dipende esattamente per ciascun pacchetto installato anzichè scrivermi solo la versione degli ultimi pacchetti installati: è ripetitivo e confuzionale???

----------

## comio

il mio è il nome con cui tutti mi chiamano al poli... alla fine è diventato il mio nick. E' vero... è il nick che cerca te!

----------

## MyZelF

 *comio wrote:*   

> il mio è il nome con cui tutti mi chiamano al poli... alla fine è diventato il mio nick. E' vero... è il nick che cerca te!

 

 :Shocked: 

Mi sono perso qualcosa o questa risposta dovrebbe stare in un altro topic?   :Laughing: 

----------

## Gandalf98

A parte il post dirottato, ho controllato un pò e devo dire che sotto questo punto di vista qpkg lascia a desiderare!!

etcat fa una ricerca tipo grep negli ebuild (se ho capito bene?) mentre invece qpkg non so su cosa si basi per i suoi risultati, sembra che non tenga in considerazione la versione del pacchetto 

```
mm-sources # qpkg -q -I gtk+

x11-libs/gtk+-2.2.4-r1 *

DEPENDED ON BY:

        gtkspell-2.0.4

        pygtk-2.0.0

        gimp-1.3.22

        imlib-1.9.14-r1

        libquicktime-0.9.2_pre1

        alsa-tools-0.9.8

        easytag-0.30

        xmms-1.2.7-r20

        pan-0.14.0

        gtkglarea-1.99.0

x11-libs/gtk+-1.2.10-r10 *

DEPENDED ON BY:

        gtkspell-2.0.4

        pygtk-2.0.0

        gimp-1.3.22

        imlib-1.9.14-r1

        libquicktime-0.9.2_pre1

        alsa-tools-0.9.8

        easytag-0.30

        xmms-1.2.7-r20

        pan-0.14.0

        gtkglarea-1.99.0
```

gimp-1.3.22 dovrebbe dipendere solo da gtk+-2.2 (come d'altronde è scritto nell'ebuild!!!), stessa cosa per xmms che secondo qpkg dipende da gtk+2 (magari!!!  :Very Happy:  )

Come conclusione qpkg nelle sue query non controlla le versioni delle dipendenze!! Sbaglio???

Cià

----------

## comio

sto facendo vecchio... eppure ricordo di averlo postato sull'altro topic  :Neutral: 

mi scuso

----------

## teknux

questo topic capita a puntino, anzi avevo fatto un post in proposito in un altro topic proprio ieri...

domenica mi sono ripulito il sistema ed ho fatto un mix di comandi:

1) emerge regen

2) regenworld

3) emerge --depclean -p >> delclean.txt

4) controllando il file depclean.txt ho cominciato ad interrogare i pacchetti della lista con "qpkg -q -I" accertandomi di non stare per cancellare qualcosa di importante

5) sistemato il file world

6) emerge --depclean

si ci ho messo un sacco di tempo e come procedura non è affatto pratica (per non parlare della tanto ricercata *eleganza* ) ma spero di aver tolto tutto il superfluo senza aver fatto danni...

ad ogni modo se c'è una cosa che purtroppo è ancora difficile gestire con gentoo, anzi diciamo portage, è proprio la pulitura del sistema di pacchetti/dipendenze obsolete/inutili. imho il primo passo è sicuramente quello di porre attenzione maniacale a ciò che si installa. a volte non installo dei programmi solo perchè richiedono librerie o pacchetti atte solo a uno scopo, anche se si tratta di pochi kb preferisco rinunciare e cercare un alternativa...

speriamo si possa risolvere questo *problema* in futuro, del resto non credo siamo gli unici a notare questa piccola carenza...

saluti,

tek

----------

## Peach

perdonami, ma regen nn c'è nel portage tree

e mi pare che:

```
# qpkg -fp regenworld

sys-apps/portage *
```

ma poi che fa di preciso regenworld? nn ho trovato un help o un man... dal nome sembra che rigeneri i pacchetti in world... ma nn ha molto senso  :Very Happy: 

----------

## Gandalf98

emerge regen l'ho fatto stamattina e rigenera tutta la cache del portage, inutile dire che ci mette un bel pò!

regen world penso rigeneri il file world inserendo i pacchetti installati ma che non vi sono presenti! 

Anche io ho cercato un pò di doc, ma non ho trovato molto! Quindi non ne sono sicuro al 100%

Cià

----------

## Peach

 *man emerge wrote:*   

>  regen  Causes  portage  to check and update the dependency cache of all
> 
>               ebuilds in the portage tree.  The cache  is  used  to  speed  up
> 
>               searches  and the building of dependency trees.  This command is
> ...

 

----------

## teknux

 *Peach wrote:*   

> perdonami, ma regen nn c'è nel portage tree
> 
> e mi pare che:
> 
> ```
> ...

 

dunque: effettivamente non c'è molto in giro, ma l'ho scoperto grazie a un post di fedeliallalinea in questo topic...

quanto alla sua utilità, quello che so è la stessa cosa che detto gandalf. io per non sbagliare ho seguito quella procedura anche se potrebbe fare cilecca, per questo ho dovuto controllare prima ogni singolo pacchetto ed evetualmente aggiungerlo al world a mano, prima di disinstallare...

saluti,

tek

----------

## Gandalf98

Lo script di regenworld è abbastanza facile!! 

L'ho capito persino io!!!

Controlla il file di log di emerge lo ordina, elimina i doppi ..

Il file ottenuto lo sostituisce al vecchio world!!

Cià

----------

## Peach

 *teknux wrote:*   

> 
> 
> 4) controllando il file depclean.txt ho cominciato ad interrogare i pacchetti della lista con "qpkg -q -I" accertandomi di non stare per cancellare qualcosa di importante
> 
> 5) sistemato il file world
> ...

 

cosa intendi per:

"5) sistemato il file world"  :Question: 

Io avrei dato subito l'emege --depclean e poi un emerge -DUpv world per far riemergere pacchetti essenziali (ok che a volte potrebbe essere dannoso.. quindi forse una via di mezzo tra questa e la tua via) poi rimeregerei a mano i pacchetti che mi aveva tolto (tipo a me ora mi toglierà genlop!?)

----------

## teknux

 *Peach wrote:*   

> 
> 
> cosa intendi per:
> 
> "5) sistemato il file world" 
> ...

 

voglio dire che a volte il --depclean vorrebbe togliere anche pacchetti che sono dipendenze o che non ho assoluta voglia di eliminare.

ad esempio, qualche tempo fa, in un "--depclean -p" è comparso (tra i vari) nmap  :Shocked: 

mentre domenica voleva togliermi libxml e libxslt, oltre ad altre librerie necessarie che ora non ricordo :/

quindi ho dovuto *sistemare* (cioè editare) il file world a mano includendo quei pacchetti. poi mi sono riaccertato che il --depclean avrebbe cancellato solo le cose *inutili* ed infine ho lanciato il --depclean vero e proprio.

come ho già detto, è un'operazione abbastanza pallosa che in realtà potrebbe essere automatizzata con uno script in bash che filtra l'output di  "--depclean -p", interroga con "qpkg -q --installed" e se non trova niente lo elimina, altrimenti lo aggiunge in automatico al file world, potrebbe essere un'idea  :Wink: 

provo a scriverci due righe appena ho tempo, vediamo se può funzionare  :Wink: 

saluti,

tek

----------

## doom.it

In pratica volevo dire la stessa cosa di teknux, cerco di dirla in mdoo un po piu ordinato (non odiarmi per questo):

RIPULIAMO DA DIPENDENZE INUTILI

1) Interroghiamo portage per sapere quali pacchetti installati non sono nè richiesti esplicitamente dall'utente, o richiesti da altri pacchetti e quindi installati come dipendenze.

```
 # emerge -p depclean 
```

avremo un output di questo tipo

```

....

media-libs/jbigkit

    selected: 1.4

    protected: none

    omitted: none

....

```

2) Controlliamo che l'indicazione del comando precedente fosse corretta, usando a mano, per ogni pacchetto listato sopra, il comando qpkg

```

# qpkg -I -v -q jbigkit

```

a questo punto se il comando non ci indica nessun pacchetto che dipende da questo, siamo contenti e passiamo a eliminare il pacchetto che non ci interessa:

```

# emerge unmerge jbigkit

```

Se invece il pacchetto fosse dipendenza di qualcosa vedremmo:

```

media-libs/jbigkit-1.4 *

DEPENDED ON BY:

imagemagick-5.5.7.11

```

Se il programma è da noi desiderato, allora ovviamente non elimineremo jbigkit, altrimenti quello dipendente cessa di funzionare. Se non sappiamo cosa sia quel pacchetto ripetiamo il comando sopra per imagemagick per capire se anche quel pacchetto è dipendenza di qualcosa desiderato e cosi via...

3) Controlliamo di non aver tolto qualcosa di troppo

```

# emerge -uDp world

```

se cosi fosse emergiamo il necessario

NOTA: Se emerge -p depclean riporta qualcosa che noi vogliamo esplicitamente che sia installato indipendentemente dal fatto che serva per qualche altro pacchetto, aggiungiamolo a mano nel file di world

/var/cache/edb/world

con un qualunque editor di testo aggiungiamo una riga in tutto e per tutto analoga alle altre gia presenti  :Wink: 

NOTA BENE: 

Il controllo manuale per la mia esperienza è necessaria soprattutto per le dipendenze di pacchetti installati due volte su slot diversi, esempio se installo sia gimp-1.2 che gimp-1.3 puo essere che 

emerge -p depclean dia come risultato delle dipendenze di uno dei due...

----------

## teknux

si doom.it sei stato sicuramente più chiaro di me, io ho tralasciato i particolari  :Wink: 

tornando su questo discorso, mi sono messo a smanettare con un po' di bash per vedere se è possibile automatizzare questa procedura, visto che sono operazioni abbastanza elementari...

purtroppo non sono un dio nelle "espressioni regolari", e sono riuscito a grep-pare un po' di output, fin qui è facile. ora viene la parte difficile, quindi lo chiedo a voi e può darsi che insieme si possa tirar su qualcosa  :Wink: 

con questo becco la lista dei pacchetti che dovrebbero essere cancellati, e li interrogo uno alla volta per vedere se sono dipendenze di qualcosa.

```

for i in $(emerge --depclean -p | grep \/) ; do qpkg -nc --installed -q $i ; done
```

fin qui è elementare. ora si pone il problema peggiore

devo filtrare in modo che lo script *capisca* cosa sia una dipendenza e cosa no. giocate con qualche output, io l'ho fatto fino a poco fa ma con scarsi risultati pratici.

se qpkg avesse riportato "0" output in caso di mancate dipendenze era facile, bastava un "if statement", purtroppo invece è troppo incasinato e ci sono troppi casini, infatti ecco cosa uscirebbe (depclean.txt è un file dove ho buttato l'output di depclean qualche giorno fa):

```

brainbox ~ # for i in $(cat depclean.txt | grep \/) ; do qpkg --installed -nc -q $i | grep -v ^D ; done

net-www/mozilla-1.4-r3

games-emulation/psemu-cdriso-1.4

media-libs/libid3tag-0.15.0b

        arts-1.1.4

games-emulation/psemu-cdriso-1.4

games-emulation/psemu-cdr-1.8

dev-util/yacc-1.9.1-r1

        wine-20031016

games-emulation/psemu-padjoy-0.81

games-emulation/psemu-padxwin-1.6

```

come potete notare i pacchetti-dipendenza hanno delle righe sotto che cominciano con degli spazi, mentre quelli *normali* no. io non riesco a filtrare in modo da determinare quale linea sia giusta e quale no :/

passato questo scoglio, in base all'output di scrivono i pacchetti in word, e gli altri che non sono dipendenza di niente si sparano in dialog con i checkbox (alla mirrorselect per capirci  :Very Happy: ) per avere un'ultima conferma prima della loro eliminazione.

verrebbe davvero un bel lavoretto  :Wink: 

in bocca al lupo, ci vediamo fra un paio di giorni  :Wink: 

saluti,

tek

----------

## HexDEF6

Magari dico una cosa ovvia, ma magari qualcuno non lo sa...

se per sbaglio disinstallate qualcosa che non doveva essere disinstallato provate a lanciare da root

revdep-rebuild

controlla tutte le dipendenze e se manca qualcosa lo emerge!

Ciao!

----------

## Peach

molto interessante!!!

in pratica si ridurrebbe il tutto a lanciare

```
# emerge regen

# regenworld

# emerge --depclean

# revdep-rebuild
```

ma con un controllo un po'... lazy... sarebbe da usare parte dello script di revdep-rebuild per scoprire dopo aver lanciato un emerge --depclean -p quali pacchetti devo essere lasciati stare...

PS: ho appena scoperto che non esiste più metacity-setup !!!  :Surprised: 

----------

## Peach

posso dirlo?

secondo me revdep-rebuild va un ca**o!  :Confused: 

lo lancio la prima volta e mi da questo output

```
# revdep-rebuild -p

 

Checking reverse dependencies...

Packages containing binaries and libraries broken by any package update,

will be recompiled.

 

Collecting system binaries and libraries... done.

  (/root/.revdep-rebuild.1_files)

 

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

 

Checking dynamic linking consistency...

  broken /sbin/ksymoops (requires libbfd-2.13.90.0.18.so)

  broken /usr/lib/libgnomeprint-2.so.0.0.0 (requires liblinc.so.1)

  broken /usr/lib/libgnomeprintui-2.so.0.0.0 (requires liblinc.so.1 liblinc.so.1)

  broken /usr/lib/gnome-panel/gnome_swallow (requires liblinc.so.1)

  broken /usr/bin/gnome-spell-properties-capplet (requires libgal.so.21)

  broken /usr/bin/gdmlogin (requires liblinc.so.1)

  broken /usr/bin/gdmflexiserver (requires liblinc.so.1)

  broken /usr/bin/gdmsetup (requires liblinc.so.1)

  broken /usr/bin/xine-remote (requires libtermcap.so.2)

  broken /usr/bin/gdmphotosetup (requires liblinc.so.1)

  broken /usr/bin/gnome-spell-component-0.5 (requires libgal.so.21)

  broken /usr/bin/gdmXnestchooser (requires liblinc.so.1)

  broken /usr/bin/gdmchooser (requires liblinc.so.1)

  broken /usr/bin/gdm (requires liblinc.so.1)

  broken /usr/bin/libgnomeprint-2.0-font-install (requires liblinc.so.1)

  broken /usr/bin/gdmgreeter (requires liblinc.so.1)

ldd: warning: you do not have execution permission for `/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so'

  broken /opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so (requires libdb-3.1.so)

ldd: warning: you do not have execution permission for `/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so'

  broken /opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so (requires libgmp.so.3)

 done.

  (/root/.revdep-rebuild.3_rebuild)

 

Assigning files to ebuilds... done.

  (/root/.revdep-rebuild.4_ebuilds)

 

Evaluating package order... done.

  (/root/.revdep-rebuild.5_order)

 

All prepared. Starting rebuild...

emerge --oneshot --nodeps -p =app-office/openoffice-bin-1.1.0 =app-text/gnome-spell-0.5 =gnome-base/gdm-2.4.1.6 =gnome-base/libgnomeprint-1.116.1 =gnome-base/libgnomeprintui-1.116.0 =gnome-extra/gnome-swallow-1.1 =media-video/xine-ui-0.9.21 =sys-kernel/ksymoops-2.4.9

 

These are the packages that I would merge, in order:

 

Calculating dependencies ...done!

[ebuild   R   ] app-office/openoffice-bin-1.1.0

[ebuild   R   ] app-text/gnome-spell-0.5

[ebuild   R   ] gnome-base/gdm-2.4.1.6

[ebuild   R   ] gnome-base/libgnomeprint-1.116.1

[ebuild   R   ] gnome-base/libgnomeprintui-1.116.0

[ebuild   R   ] gnome-extra/gnome-swallow-1.1

[ebuild   R   ] media-video/xine-ui-0.9.21

[ebuild   R   ] sys-kernel/ksymoops-2.4.9

 

Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
```

va be...

tolgo il -p e lo rilancio.

Risultato? Si blocca installando gnome-spell: il configure non trova le librerie GAL.

Ok dico io, reinstallo GAL,

Rifaccio partire revdep-rebuild -p e cosa ottengo? LO STESSO IDENTICO RISULTATO...

ok mi sarò sbagliato... rifaccio tutto e cosa ottengo? LO STESSO IDENTICO ERRORE! librerie GAL missing...  :Twisted Evil: 

Ora sto emergiando manualmente i pacchetti che rimaneva ma sinceramente non capisco da cosa sia nata sta novità... dopo do un occhio ai filez che ti crea revdep-rebuild per vedere se c'era qualche istruzione particolare per emerge.

se qualcuno sa dire qualcosa in più riguardo a questo..

PS: e poi openoffice-bin è andato a richiamare!?!?! che assurdità... mah

----------

## cerri

Questo post e' lunghissimo.........

CMQ, per verificare i pacchetti installati con piu' versioni basta fare

```
$ qpkg --dups -v
```

----------

## HexDEF6

 *Peach wrote:*   

> posso dirlo?
> 
> secondo me revdep-rebuild va un ca**o! 
> 
> <--SNIP-->
> ...

 

Hai cancellato tutti i file che ti crea in /root/  ???

Non mi ricordo come si chiamano (se ci dai un occhio capisci subito quali sono), ma prima di rilanciarlo devi cancellarli tutti!

Ciao!

----------

## Peach

 *HexDEF6 wrote:*   

> 
> 
> Hai cancellato tutti i file che ti crea in /root/  ???
> 
> Non mi ricordo come si chiamano (se ci dai un occhio capisci subito quali sono), ma prima di rilanciarlo devi cancellarli tutti!
> ...

 

sisi! per quello dico che nn va!!!

```
# rm /root/.revdep-rebuild*.?_*
```

----------

## teknux

ripesco il post perchè non mi sono ancora arreso per la mia idea. ho creato uno scriptino che per il momento mostra i pacchetti candidati all'emliminazione di un "emerge --depclean" con il relativo numero di dipendenze. purtroppo dalle prove restano ancora dei problemini, spero che qualcuno possa contribuire al lavoro:

```

#!/bin/sh

PKX=`for i in $(emerge -p --depclean | grep \/) ; do DEPS=\`qpkg -nc -q--installed $i | grep -v ^D | wc -l | tr -d ' '\` ; let DEPS-=1 ; printf "$i DEPENDS_ON:${DEPS} OFF " ; done`

dialog --title "DEPCLEAN SELECTOR" --separate-output --checklist "Select packages to add in word file" 0 0 0 $PKX 2>&1

```

al momento mostra solamente e premendo su "OK" stampa a video i pacchetti segnati. devo ancora decidere come portare avanti lo script. probabilmente sarà più facile far aggiungere nel file world i pacchetti segnati. lasciando all'utente il comando di depclean vero e proprio da fare a mano.

il problema di cui parlavo riguarda il fatto che di alcuni programmi stampa anche la versione, perciò non è una gran cosa da aggiungere nel world...

sono stato alcune ore tra documenti e man pages a smanettare con vari programmi per filtrare (sed, awk, expr) le stringhe e togliere il numero di versione ma con risultati abbastanza deludenti. o meglio: toglievo la versione ma poi non mi stampava più le stringhe normali (quelle senza versione per capirci)...

mi rimetto a voi  :Wink: 

saluti,

tek

per ora si limita solo a mostrare in un dialog i pacchetti

edit: attenzione, che il codice postato ha preso una brutta formattazione. le istruzioni sono due e vanno messe su una sola riga...

----------

## silian87

l'ho provato, bello script, bravo. Pensavo che sarebbe fico fare una gui per emerge (vi prego non impiccatemi per questa affermazione). In questo modo lo possiamo far apparire piu' bello ai nuovi utenti. Per esempio quanto senso di proffessionalita' non ti da il package manager di mandrake? 

La gui sarebbe da fare con intelligienza, un po' come gvim, che ti da i menu' per i comandi, ma poi ti fa vedere anche il vero comando e le shourt cut. Credo che verrebbe un bel lavoro, me lo immagino gia'... Nessuno vorrebbe aiutarmi ad iniziarlo, io conosco emerge, ma ho bisogno di un esperto al fianco per fare un buon tool...

----------

## silian87

 :Laughing:   :Laughing:  Sembrerebbe che quelli di kemerge ci abbiano gia' pensato   :Laughing:   :Laughing:  . Ma comunque non mi piace, include solo l'opzione pretend, niente ricerche o altro, non usa il discorso che ho fatto su gvim e poi usa le qt.... credo che si possa fare, allora

----------

## morellik

silian87, mi piacerebbe l'idea di fare qualcosa, che potrebbe essere il primo (?) prodotto dei Gechi    :Very Happy: 

Io conosco abbastanza python e sarei dell'idea di fare un prodottino che giri sotto tutti

i WM senza limitazioni e con un minimo di librerie necessarie.

Che ne dite? Ci buttiamo? Ce lo facciamo un progettino GECO (Gechi Emerge Client Organizer) su sourceforge?   :Cool: 

Ciauz

morellik

----------

## Ash y Nod

Maaa scusate,riassumendo,c'è un modo più o meno sicuro di fare un unmerge e pulire le dipendenze?

Qualcuno farebbe un riassunto di tutte le proposte fatte in questo Thread che onestamente non ce ne ho capito più niente...   :Embarassed:   :Rolling Eyes:   :Crying or Very sad: 

----------

## shev

 *morellik wrote:*   

> 
> 
> Che ne dite? Ci buttiamo? Ce lo facciamo un progettino GECO (Gechi Emerge Client Organizer) su sourceforge?   

 

Perchè no, magari con le ncurses così è indipendente non solo da un wm/de, ma pure da X.

Sul python invece non si discute  :Very Happy: 

Non so se e quanto potrò aiutare (sono vicino all'overflow del mio buffer-impegni), però come idea potrebbe essere interessante e valida. Ovviamente sempre che nessun altro ci abbia già pensato: oltre a kemerge mi pareva ci fossero altri progetti simili. Anche se cmq non vuol dire che il nostro non possa essere migliore degli altri  :Wink: 

----------

## Peach

se posso permettermi il sunto potrebbe essere dato da questi step:

Ripulire il Sistema

1 - Metodo Manuale (non certificato)

NOTA: i cambiamenti di flag potrebbero influenzare sensibilmente i pacchetti coinvolti

1)

```
# emerge regen

# regenworld
```

2)

```
# emerge -p depclean
```

che restituisce un listato di pacchetti simile a questo:

```
....

dev-libs/geoip

    selected: 1.2.1

    protected: none

    omitted: none

....
```

la necessità che insorge è che depclean non desideri cancellare pacchetti che a noi interessa mantenere (ad esempio geoip è usato da nicotine)

quindi non ci resta che controllare se viene richiesto da qualche pacchetto con:

3a)

```
# qpkg -I -v -q geoip
```

l'unico problema che è insorto è che qpkg in caso di pacchetti doppi (tipo gimp 1.2 e 1.3 che vengono installati in slot diversi) non fa caso alle differenti dipendenze per ciascuna versione: quindi meglio usare in questo caso:

3b)

```
# etcat -d geoip
```

che invece presenta la debolezza che fa vedere tutte le dipendeze di tutti i pacchetti.. anche quelli non installati.

nel caso i pacchetti non siano dipendenza di nessun altro pacchetto installato siamo tranquilli e possiamo lanciare

4a)

```
# emerge depclean
```

4b)

nel caso i pacchetti siano dipendenza di qualche altro programma basterebbe inserire la loro presenza nel file di world manualmente ( /var/cache/edb/world ) oppure lasciare che depclean faccia il suo compito e riemergerli sucessivamente.

----------

## HexDEF6

 *silian87 wrote:*   

> l'ho provato, bello script, bravo. Pensavo che sarebbe fico fare una gui per emerge (vi prego non impiccatemi per questa affermazione). In questo modo lo possiamo far apparire piu' bello ai nuovi utenti. Per esempio quanto senso di proffessionalita' non ti da il package manager di mandrake? 
> 
> La gui sarebbe da fare con intelligienza, un po' come gvim, che ti da i menu' per i comandi, ma poi ti fa vedere anche il vero comando e le shourt cut. Credo che verrebbe un bel lavoro, me lo immagino gia'... Nessuno vorrebbe aiutarmi ad iniziarlo, io conosco emerge, ma ho bisogno di un esperto al fianco per fare un buon tool...

 

ha mai provato kportage???

Ciao!

----------

## Gandalf98

 *HexDEF6 wrote:*   

> ha mai provato kportage???
> 
> Ciao!

 

Lo usi ancora? A me con le ultime versioni di portage ha smesso di funzionare!!

Cià

----------

## teknux

ragazzi se vi può interessare io sarei a buon punto... lo script ora comincia a funzionare decentemente, nel senso che svolge le parti basilari finali. inoltre appoggiandomi a dialog (o volendo xdialog) il problema di farlo girare tranquillamente in ambiente grafico e testuale non si pone.

posto qui l'ultima la bozza di codice. grazie a ^Useless^ incontrato in chat, ora c'è una regex che toglie il numero di versione da alcuni pacchetti visualizzati. manca da aggiungere le varie fasi iniziali, ma quelle sono le più facili a mio avviso  :Wink: 

```

#!/bin/sh

TMPFILE=./clean.txt

PKX=`for i in $(emerge depclean -p | grep \/) ; do DEPS=\`qpkg -nc -q --installed $i | grep -v ^D | wc -l | tr -d ' '\` ; let DEPS-=1 ; printf "$i DEPENDS_ON:${DEPS} OFF " ; done`

dialog --title "DEPCLEAN SELECTOR" --separate-output --checklist "Select packages to add in word file" 0 0 0 $PKX 2>&1 | sed -ne "s/-[0-9].*\..*$//; p" >> $TMPFILE

echo -n "Adding following records to /var/cache/edb/world file..."

for i in $(cat $TMPFILE) ; do

        if ! grep -x $i ./world &>/dev/null ; then

                echo $i >> ./world

        fi

done

echo "done.\n"

```

come nel mio post precedente, attenzione perchè le prime istruzioni vanno su una riga sola. dovrei aggiungere un carattere "/" per spezzare le righe, lo farò appena avrò tempo. intanto se volete provare cosa dovrebbe apparire nel dialog accomodatevi perchè fin qui funziona. verrà visualizzato l'output di "emerge --depclean -p" con il controllo di eventuali dipendenze dai singoli pacchetti (visualizza il numero di pacchetti dipendenti dai pacchetti selezionati dal depclean). nel dialog si possono selezionare i pacchetti che NON si vogliono eliminare e quando premerete OK lo script controlla che tali pacchetti sianno contenuti nel world ed eventualmente li aggiunge.

fate caso che il file world non è quello originale perchè durante le prove, ovviamente, ho copiato il world in una directory facendo le prove su quello.

ora basta aggiungere all'inizio i comandi di "emerge regen" e "regenworld", magari redirectando l'output in /dev/null e stampando un messaggio personalizzato.

insomma, la base è pronta, spero possa interessarvi  :Wink: 

saluti,

tek

----------

## Peach

beeeeeello  :Surprised: 

 *Quote:*   

> Select packages to add in world file

 

mancava una l, giusto per correttezza

----------

## teknux

per i curiosi, ho messo qui uno shot di come appare.

sono 73k a 800x600

saluti,

tek

----------

## Peach

scusa nn è cattiveria.. ma com'è che a te vengono fuori quelle strane lettere tutt'attorno?  :Confused: 

[img:dd0364df2c]http://www.zopen.it/peach/works/gentoo/Screenshot-depclean.gif[/img:dd0364df2c]

----------

## shev

Ottimo, altro parto azzeccato delle menti del gechi!  :Very Happy: 

A questo punto credo che di cose da mettere sul futuro sito del Gechi (di cui ci occuperemo appena passato il Linux Day) ce ne siano, grandi ragazzi!

----------

## teknux

 *Peach wrote:*   

> scusa nn è cattiveria.. ma com'è che a te vengono fuori quelle strane lettere tutt'attorno? 
> 
> 

 

sinceramente non ne ho la più pallida idea... ho installato dialog tempo fa come dipensenza di mirrorselect. ad ogni modo me lo stavo chiedendo pure io...   :Rolling Eyes: 

----------

## neon

Allora... oggi pom ho scoperto zenity (una util per creare dialogs gtk+ inclusa in gnome)

avrei scritto un porting in phyton dello script...

[img:53144e92ba]http://web.lacasadialice.it/annoiato/pkgclean.jpg[/img:53144e92ba]

Ora non ho proprio il tempo di completarlo (deve solo includere l'output del dialog nel file world)

ma credo che domani potrò postarne il codice  :Wink: 

Esiste qualcosa di simile per kde??? dato che so che molti di voi usano questo pappa risorse  :Very Happy: 

----------

## silian87

Bel lavoro ragazzi, proprio bello. Forse e' meglio usare gtk+, non qt, perche' sono piu' leggere, e poi mica dobbiamo fare la gioconda. Adesso analizzo un po' lo script.

----------

## teknux

 *neon_it wrote:*   

> 
> 
> avrei scritto un porting in phyton dello script...
> 
> 

 

di quale script? io ci avevo fatto un pensiero a usare python, ma visto che potevo fare le stesse operazioni in bash ho evitato  :Wink: 

 *Quote:*   

> Esiste qualcosa di simile per kde???

 

intendi kemerge?

 *Quote:*   

> dato che so che molti di voi usano questo pappa risorse 

 

ehheheh dipende quanto vuoi fargliene pappare, a sistema appena acceso ho 45mb totali di ram occupata (secondo gkrellm), un buon compromesso prestazioni/occupazione no?  :Wink: 

un'ultima cosa: nello screenshot che hai postato, viene mostrato anche il nome dei programmi che dipendono dai pacchetti da togliere: nel caso siano più di uno, come vengono visualizzati? just curiosity  :Wink: 

saluti,

tek

----------

## neon

 *teknux wrote:*   

> intendi kemerge?

 

intendo un crea dialog...

 *teknux wrote:*   

> un'ultima cosa: nello screenshot che hai postato, viene mostrato anche il nome dei programmi che dipendono dai pacchetti da togliere: nel caso siano più di uno, come vengono visualizzati? just curiosity 

 

Ho un dizionario del tipo:

```
ebuild = {"NAME":"nomepacchetto", "VERSION:"versione", "DEPS":"['dep1','dep2','dep3']"}
```

al generatore di dialog li passo come "dep1 dep2 dep3" così li vede come parametro unico  :Wink: 

----------

## teknux

 *neon_it wrote:*   

> 
> 
> Ho un dizionario del tipo:
> 
> ```
> ...

 

non è che puoi postarmi uno shot con visualizzate più dipendenze? voglio capire come dovrebbe apparire   :Smile: 

per quanto riguarda i dialog sotto kde non ho trovato nulla. ma ho scoperto una bella libreria python per dialog testuali  :Very Happy: 

 si chiama pythondialog e si trova in portage  :Smile: 

saluti tek

----------

## neon

Ecco lo script dello screenshot, ora è completo. Ho eliminato il controllo sulla versione (mi sono accorto che non serviva). Se trovate dei bug sistematelo (l'ho scritto questo pom ed ho ultimato la funzione insall proprio ora [sonno])

```
#! /usr/bin/env python

import commands, re

def find(string,sub):

  p = re.compile(sub)

  result = p.findall(string)

  return result

def depclean():

  cmd = "emerge -p depclean"

  str1 = "\w*-*\w*\/\w*-*\w*"

  out = commands.getoutput(cmd)

  list = find(out, str1)

  return list

def search(list):

  cmd = "qpkg -I -nc -q "

  list2 = []

  for i in list:

    depslist = ""

    out = commands.getoutput(cmd + i)

    deps = find(out, "\t.*")

    for j in deps:

      depslist += j[1:] + " "

    ebuild = {"NAME":i, "DEPS":depslist}

    list2.append(ebuild)

  return list2

def display(list):

  out = ""

  for i in list:

    out += " FALSE \"" + i["NAME"] + "\" \"" +i["DEPS"] + "\""

    cmd ="zenity --list --checklist --column \"Add\" --column \"Ebuild\" --column \"Dependency of\" " \

  + out

  output = commands.getoutput(cmd)

  return output

  

def install(output):

  out = output.split("|")

  file = open("/var/cache/edb/world", "a")

  for i in out:

    file.write(i + "\n")

  file.close()

list = depclean()

list = search(list)

output = display(list)

if output:

  install(output)

```

Dipende dal pacchetto gnome-extra/zenity.

Fate conto che è lento perchè effettua ogni volta un "emerge -p depclean"

Per kde ho letto che esiste kdialog che fa esattamente la stessa cosa di zenity, siccome mi secco ad installare tutte le qt a voi modificare la funzione display per utilizzarlo con kde  :Wink: 

Dimenticavo:

 *teknux wrote:*   

> di quale script?

 

Del tuo  :Razz: 

L'idea di automatizzare il tutto è stata tua no? io ho solo scritto il prog in python...

----------

## Peach

Veramente ottimo...

però...

a mio personale parere creare nuove dipendenze non ha molto senso.

Sinceramente trovo molto + comodo una pseudo-interfaccia in console stile ncurses e _POI_ pensare ad una interfaccia per X, ma questo è un fattore secondario...

Pensate se poteste collegarvi solo via ssh alla vostra macchina... ora esagero ma penso che il concetto sia questo.

I miei due rubli.

----------

## neon

 *Peach wrote:*   

> a mio personale parere creare nuove dipendenze non ha molto senso.

 

Considerando che zenity viene installato da gnome-2.4 è una dipendenza solo per chi non usa gnome. Idem kdialog per kde. Chi non usa ne gnome ne kde può sempre usare lo script bash  :Very Happy: 

 *Peach wrote:*   

> Sinceramente trovo molto + comodo una pseudo-interfaccia in console stile ncurses e _POI_ pensare ad una interfaccia per X

 

Non esisteva già quello per console?  :Razz: 

----------

## Peach

apposto.

per niente avevo dato due rubli di pensiero.  :Laughing: 

/me va a dormire dopo 3 giorni di uptime fisico

----------

## teknux

a uqesto punto mi trovo davanti a un bivio:

1) continuare lo script in bash

2) continuare l'ottimo lavoro di neon.it  :Wink: 

sono propenso per la seconda, anzi ho già una bella ideona in testa:

1) aggiungere una funzione di getopt dove si potrà scegliere quale guid usare, ed ecco la parte interessante: in base alla gui si potrà scegliere tra zenity, kdialog, oppure si aggiunge la libreria pythondialog o addirittura lo stesso dialog (che molti troveranno già se posseggono mirrorselect...). in questo modo basterebbe solo cambiare la variabile cmd della funzione display  :Very Happy: 

se mi date qualche parere ne sarei felice, nel frattempo mi metto al lavoro  :Wink: 

saluti,

tek

ps: complimenti neon.it !  :Very Happy: 

----------

## shev

 *teknux wrote:*   

> 
> 
> se mi date qualche parere ne sarei felice, nel frattempo mi metto al lavoro 

 

Tu-tto! Tu-tto! Tu-tto!

Siamo una comunità che ama scegliere, quindi vogliamo tutte le interfacce possibili!  :Wink: 

p.s.: già mi immagino un ebuild che a seconda della USE che si mette ci piazza l'interfaccia giusta  :Very Happy: 

----------

## teknux

 *Shev wrote:*   

> 
> 
> Tu-tto! Tu-tto! Tu-tto!
> 
> Siamo una comunità che ama scegliere, quindi vogliamo tutte le interfacce possibili! 
> ...

 

eheheh purtroppo già per kdialog questo discorso non si può fare... ha delle opzioni limitatissime per quello che ci serve, quindi va escluso a priori... per ora ho sostituito zenity con il semplice "dialog" testuale, che è sempre meglio di niente (nel senso di chi non ha gnome).

 *Quote:*   

> 
> 
> p.s.: già mi immagino un ebuild che a seconda della USE che si mette ci piazza l'interfaccia giusta 

 

continuo a pensare che io e te abbiamo dei collegameti tele-sinaptici: i pensieri ci viaggiano in comune  :Wink:  è proprio quello che avevo in testa.

sono tremendamente indeciso su come modificare lo script di neon.it, ecco alcuni dis-appunti (modificabili):

1) mostra i nomi dei pacchetti dipendenti, il pro è che si ha una vista immediata, il contro è che è quasi impossibile gestire diversi tipi di dialog in quel modo. pensate sia meglio presentare solo il numero di pacchetti dipendenti, o preferite anche i nomi? per ora ho modificato lo script per mostrare solo il numero, togliendo i nomi. purtroppo mostrando i numeri possono sfuggire quei pacchetti che sono presenti in più versioni, facendo un conto unico (es con le gtk somma le dipendenze di gtk 1 e 2).

2) questa è solo una mancanza che sto per aggiungere: voglio controllare prima che il pacchetto che non voglio togliere non sia contenuto nel file world per evitare che venga scritto due volte, magari è una semplice ridondanza, ma meglio abbondare  :Wink: 

infine penso che a questo punto sia inutile continuare quello in bash   :Rolling Eyes: 

saluti,

tek

----------

## Peach

 *Shev wrote:*   

> 
> 
> Tu-tto! Tu-tto! Tu-tto!
> 
> Siamo una comunità che ama scegliere, quindi vogliamo tutte le interfacce possibili! 
> ...

 

fiQissimo!  :Laughing: 

ma scusa...

io sostengo che il programmillo depclean debba essere installato senza nessun costo aggiuntivo di librerie e altro... 

Sarebbe semplice fare uno scriptino nell'ebuild o richiamabile da esso che a seconda di cosa hai installato ti installa il frontend migliore? hai le zenity? hai +gnome? hai ...?

sono stato abbastanza confuso?

----------

## teknux

purtroppo come dicevo nello scorso post non è affatto facile (per non dire quasi impossibile) gestire diversi tipi di dialog in ncurses, qt o gtk/gnome. hanno opzioni e modi di presentare i contenuti troppo differenti. si può provare ma io preferirei rimandare un po' prima di pensarci...

nel frattempo ho scoperto che il pacchetto pythondialog non è altro che un solo file sorgente .py e contiene (togliendo alcuni commenti e l'esempio incluso nel sorgente) davvero poche linee di codice. non solo: essendo una classe, si potrebbe addirittura tagliare le parti che non servono lasciando solo quelle necessarie. in questo modo si avrebbe un bel programmino in python completo e privo di dipendenze esterne con una bella interfaccia testuale (tanto non venitemi a dire che statisticamente non lanciate emerge da linea di comando....). il porgramma dovrebbe essere anche un pochino più leggero, credo.

ho per la testa anche l'idea di controllare i sorgenti di emerge che sono quasi certo si appoggia a qualche classe o script esterno anche per effettuare il "depclean pretend". in questo modo si può modificare l'output e cambiare drasticamente il design del nostro programma (/me immagina l'inclusione in gentoolkit o portage... /me onanista mentale).

vedo come/quando posso provare. nel frattempo mi piacerebbe ascoltare qualche parere vostro: idee, commenti, proposte...

saluti,

tek

----------

## codadilupo

ritiro fuori questo post, visto che se ne é appena parlato.

e perché, imho, e' una delle cose migliori nate qui dentro.

Com'e' che s'e' fermato qui ?

Coda

----------

## Peach

si concordo anche io nel tirarlo fuori...

insistiamo!

PS: tra l'altro mi trovo a voler disintallare gnome... mai cosa + ardua mi si presentò  :Smile: 

----------

## micron

 *Peach wrote:*   

> mi trovo a voler disintallare gnome... mai cosa + ardua mi si presentò 

 

Anche io mi sono trovato di fronte a questa ardua impresa... e, non essendo a conoscenza di questo thread, mi sono messo a scrivere un'applicazione in python per risolvere l'impresa.

Sono a buon punto, non appena inizierò ad avere dei risultati positivi vi farò sapere  :Wink: 

----------

## Peach

 *micron wrote:*   

>  *Peach wrote:*   mi trovo a voler disintallare gnome... mai cosa + ardua mi si presentò  
> 
> Anche io mi sono trovato di fronte a questa ardua impresa... e, non essendo a conoscenza di questo thread, mi sono messo a scrivere un'applicazione in python per risolvere l'impresa.
> 
> Sono a buon punto, non appena inizierò ad avere dei risultati positivi vi farò sapere 

 

qualche anticipazione a riguardo?

 :Rolling Eyes: 

----------

## micron

 *Peach wrote:*   

> qualche anticipazione a riguardo?

 

Perdonate l'alone di mistero, non è assolutamente cercato... è solo che ultimamente sono molto preso (dall'uni e da altro) e non riesco a dedicare molto tempo a questo progetto  :Arrow:  non voglio diffondere false speranze.

Ad ogni modo si tratta di un programma che serve a disinstallare in maniera pulita un programma, ovvero toglie lui e tutte le dipendenze non utilizzate da altre apps installate.

La cosa negativa, che incierà per i primi tempi (almeno fino a quando non diventerà threaded), è il fatto che il programma controlla tutte le dipendenze del programma da eliminare in maniera recursiva (per estirparlo fino alle radici  :Smile:  ). Ovviamente ho usato alcuni accorgimenti per evitare che siano controllati proprio tutti i programmi installati, però penso che il programma sarà un pelo lento.

Purtroppo ora non sono in grado di quantificare il tutto perchè sto affrontando le fasi separatamente (sono solito risolvere a "piccoli passi" lo sviluppo di un programma).

Al momento devo implementare un metodo per stabilire il rapporto tra due versioni dello stesso programma  :Arrow:  a<b || a>b || a==b

Una volta superata questa fase penso che inizierò a fare le prime simulazioni.

Come detto sopra vi farò sapere quando raggiungerò la prima fase di testing

----------

