# [Discussione] Portage ha qualche problema? Parliamone

## Cazzantonio

Intendiamoci... a me piace gento...   :Smile: 

Tuttavia ci sono un paio di dettagli (che a guardarli bene tanto dettagli non sono) che mi danno un fastidio incredibile   :Evil or Very Mad: 

Evitando di parlare dei pregi di portage visto che sono ovvi passarei direttamente a parlare dei problemi:

1)Possibile che ancora nessuno abbia sviluppato un modo intelligente per far stampare tutte le einfo, ewarn e quant'altro  di importante dica emerge alla fine di una compilazione alla fine di ogni catena di compilazioni??   :Evil or Very Mad: 

Che diavolo serve che emerge mi stampi degli avvertimenti se sto aggiornando contemporaneamente diversi pacchetti e ogni scritta permane sullo schermo solo pochi secondi (se va bene)?? Questa mi sembra davvero una presa per il culo...   :Evil or Very Mad: 

Non è nemmeno tanto difficile da implementare... basta buttare tutte le informazioni ALLA FINE e non DURANTE il processo di emersione...   :Evil or Very Mad: 

Ora qualcuno di voi dirà che con portage 2.1 si può loggare tutte queste informazioni in /var/log soluzione molto elegante...   :Rolling Eyes:  prima zero informazioni e ora troppe... logga tutto in file separati... uno per ogni pacchetto+versione... avete idea di quanti file trovate la dentro dopo qualche mese di utilizzo di gentoo?   :Rolling Eyes:  si ok che i dati ci sono tutti ma c'erano pure se mi andavo a leggere tutti gli ebuild che emergevo...  :Twisted Evil:   bah... i devel di portage hanno un concetto stravagate di usabilità  :Evil or Very Mad: 

Ripeto nuovamente... possibile che nessuno abbia ancora pensato di implementare la cosa più semplice??? ovvero stampare quelle cavolo di informazioni ALLA FINE di tutto il processo di emersione?   :Evil or Very Mad: 

2)Mi stupisce vedere quanti tool malfunzionanti ci sono in gentoolkit... equery depens non funziona granchè bene... a volte trova le dipendenze, a volte no, a volte ne trova di scorrette e a volta da risultati diversi a seconda che si inserisca il nome del pacchetto liscio o si aggiunga anche il numero di versione...   :Rolling Eyes:  Potevano sprecarsi a farlo un tantino meglio?  Sono i tool ufficiali di manuntenzione... e che ca**o  :Rolling Eyes:   :Evil or Very Mad: 

Inoltre non hanno ancora implementato seriamente una funzione quantomeno basilare... emerge --depclean non funziona affatto correttamente... lascia un sacco di spazzatura a giro e non rimuove nemmeno le vecchie versioni inutilizzate dei pacchetti slotted... ovvero se avete installato un pacchetto slotted dovete ricordarvelo voi... non esiste alcun tool ufficiale in grado di rimuovere le versioni vecchie!  :Shocked:  Immaginate solo quanto sia pratico avere 15 versioni diverse e inutili di gentoo-sources o di kdelibs.... ok direte voi... sei un utente navigato, lo sai e li rmuovi a mano... beh posso anche installarmi tutti i programmi a manina con ./configure, make e make_install però se uso una distribuzione con un gestore di pacchetti avrei piacere che li gestisse lui... almeno le cose di base...   :Rolling Eyes:   :Evil or Very Mad: 

Il fatto è che anche questa feature non è incredibilmente complessa... xchris aveva scritto in (relativamente) poco tempo unclepine che faceva tutto questo e lo faceva perfettamente... (non funziona più con portage 2.1... per questo mi girano le balle ora).   :Rolling Eyes: 

A questo punto potreste dire le seguenti cose:

Q) beh si chiama opensource non a caso... non rompere le balle e scriviti tutte le modifiche che vuoi al sorgente... che cosa protesti visto che questa è tutta gente che lavora a gratis?   :Evil or Very Mad: 

A) formalmente vero ma troppo comodo... io sono libero di protestare quanto loro di ignorarmi (con loro intendo i devel di portage e/o gentoolkit). Se avessi pagato per un prodotto avrei diritto a vedere ascoltate le mie critiche, in questo caso invece posso solo sperare che le mie critiche vengano accettate e ne sono perfettamente consapevole.   :Smile: 

Comunque io non sono un grande programmatore e nemmeno mi piacerebbe parecchio esserlo... riconosco la qualità di portage ma se dovessi mettermi a studiane il codice preferirei passare ad un'altra distribuzione e sopportare un gestore di pacchetti peggiore.   :Rolling Eyes: 

Q) quelli da te indicati non sono difetti o comunque sono cose secondarie  :Rolling Eyes: 

A) beh allora dimmi quali sono i difetti secondo te (se pensi ci siano).   :Rolling Eyes: 

Q) sei veramente astioso e questo post cola cattiveria da tutte le parti   :Evil or Very Mad: 

A) vero ma fa caldo, è l'una di notte, da ieri sto cercando di risistemare il computer (fa caldo pure a lui) dopo aver praticamente cancellato tutto il sistema operativo per sbaglio (non è colpa di gentoo). Il fatto che ci stia mettendo così tanto è imputabile a due fattori (oltre al fatto che mi si fonde il computer):

1-- non posso mettere tutto insieme a compilare perché mi perderei tutti gli einfo e gli ewarn e ci tengo a leggermeli visto che qualcuno a perso tempo a scriverli (perchè non ti stampi la lista dei pacchetti da installare e non ti leggi tutto a mano? perchè ci metterei il doppio... l'ultimo backup era di tre mesi fa e sto aggiornano circa 150 pacchetti).   :Rolling Eyes: 

2-- se al punto uno volevate dirmi "perchè non abiliti l'elog del nuovo portage" sappiate che l'ho mascherato in attesa di capire come fare a meno di unclepine... sto cercando di farmi degli scriptini a mano ma non funzionano bene come unclepine per cui per ora preferisco il vecchio portage + unclepine che quello nuovo pieno di dubbie features... se dovessi fare a meno di unclepine sarei tentato di fare a meno anche di portage e passare direttamente ad ubuntu   :Rolling Eyes:   :Twisted Evil: 

[MOD]A parte l'astio del mio post che è al 50% ironia (il resto è astio davvero   :Smile:  ) avrei piacere che non si degenerasse in un flame... anche perché altrimenti sarebbe colpa mia e mi dovrei autocensurare... fatemelo per piacere grazie...   :Smile:  [/MOD]

----------

## .:chrome:.

1) più precisamente di quali informazioni parli?

se ti riferisci ad informazioni di scarsa importanza, beh... proprio in quanto tali, io me ne frego  :Laughing: 

se invece parli di informazioni critiche, in tutti i casi che io ho visto, dopo quelle finromazioni, il processo di emerge viene interrotto in modo automatico. mi riferisco in modo particolare ad avvisi del tipo "stai aggiornando mysql. se non fai prima un dump e poi un restore rischi di perdere tutto"

2) a ben pensarci non è sbagliato che equery depends dis output diversi a seconda che metti o meno il numero di versione. possono esserci dipendenze diverse per versioni diverse, non trovi? tuttavia parlarne così ha poco senso. riusciresti a fare un esempio pratico? se poi effettivamente c'è il malfunzionamento e non si tratta di una semplice cattiva interpretazione si può (dsi deve) aprire un bug.

quanto a depclean devo davvero smentirti. funziona benissimo, a patto però che il world sia pulito, e che non sia pieno di spazzatura, altrimenti non è davvero possibile ripulire il sistema. non sono però sicuro di avere capito il tuo problema con i pacchetti slotted; in ogni caso, hai provato emerge --prune?

secondo me guardi solo il problema dal lato sbagliato. come ho brevemente cercato di dimostrare, i problemi che hai sollevato non sono nemmeno tali, se li guardi da un altro punto di vista.

tuttavia questa è una bella discussione. sicuramente un buon punto di partenza per imparare qualcosa di più su portage e/o per chiedere delle nuove funzioni tramite bugzilla

----------

## funkoolow

io una cosa che non sopporto è che quando fai il pretend del world e in mezzo c'è qualche pacchetto mascherato, invece di darti la lista di tutti i pacchetti magari con una [M] ad indicare quelli che bloccano l'emerge perchè maskati ti si ferma lì, e tu che devi inserirti a mano tutti i pacchetti uno stop alla volta nel package.keywords....

una gran perdita di tempo  :Evil or Very Mad: 

----------

## Cazzantonio

 *k.gothmog wrote:*   

> 1) più precisamente di quali informazioni parli?

 

Cose tipo "occhio che è meglio fare un revdep-rebuild" oppure "è cambiata questa cosa dalla versione precedente del pacchetto... dacci un'occhio"   :Rolling Eyes: 

Ti assicuro che non sempre portage si ferma... lo fa solo in casi davvero critici   :Smile: 

 *k.gothmog wrote:*   

> 2) a ben pensarci non è sbagliato che equery depends dis output diversi a seconda che metti o meno il numero di versione. possono esserci dipendenze diverse per versioni diverse, non trovi?

 

Si daccordo ma quello che dico è che talvolta non trova nemmeno le dipendenze... che tu gli dia la versione o meno...

poi capita anche che veda le dipendenze del pacchetto senza versione ma non del pacchetto se specifichi la versione (magari il pacchetto è slotted e ti interessa capire quali delle molteplici versioni installate sia necessaria ancora a qualcosa o meno)

 *k.gothmog wrote:*   

> tuttavia parlarne così ha poco senso. riusciresti a fare un esempio pratico? 

 

gtkglarea, gnupg, orbit, glib .... tanti altri che ora non mi ricordo... ah scusa anche gimp-print che dipende da gimp tramite l'omonima useflag ma equery non è daccordo   :Rolling Eyes: 

 *Quote:*   

> se poi effettivamente c'è il malfunzionamento e non si tratta di una semplice cattiva interpretazione si può (dsi deve) aprire un bug.

 

Ci darò un'occhiata...   :Rolling Eyes: 

 *Quote:*   

> quanto a depclean devo davvero smentirti. funziona benissimo,

 

Sono daccordo sul fatto che funzioni "quasi sempre"... ma è un "quasi" discretamente fastidioso   :Smile: 

Inoltre come già detto emerge --depclean non caga nemmeno di striscio tutti i pacchetti slotted e le loro versioni... potresti avere 15 versioni diverse delle kdelibs (di cui magari necessiti solo della più recente) e lui non farebbe una piega   :Smile: 

Ma facciamo un altro esempio... supponiamo che tu installi con emerge --oneshot gtkhtml... prima non c'era nemmeno una versione, non è dipendenza di niente, tuttavia il solo fatto che sia slotted garantisce che emerge --depclean non lo consideri nemmeno indipendentemente dal fatto che non serva più a nessuno... questo non lo vedi nemmeno con --prune   :Rolling Eyes:  (è uno solo) Diventa un vero fantasma

 *Quote:*   

> a patto però che il world sia pulito, e che non sia pieno di spazzatura

 

Ti assicuro che la pulizia del mio world rasenta un livello maniacale...   :Smile: 

 *Quote:*   

> hai provato emerge --prune?

 

 *man emerge wrote:*   

>        --prune (-P)
> 
>               WARNING:  This  action  can  remove important packages!  Tries to
> 
>               remove all but the last version  installed.   Since  the  command
> ...

 

non mi sembra questa la soluzione...   :Rolling Eyes: 

Comunque ti fa capire il livello del problema... "This does not check dependencies".... come sarebbe a dire....   :Shocked: 

Cavolo ti potevi sprecare a fare anche il check per le dipendenze?   :Rolling Eyes: 

Se ti riesce calcolare le dipendenze in fase di installazione sarà così difficile farlo una volta installati?   :Rolling Eyes: 

Il database dei pacchetti a che serve?   :Rolling Eyes: 

 *Quote:*   

> secondo me guardi solo il problema dal lato sbagliato. come ho brevemente cercato di dimostrare, i problemi che hai sollevato non sono nemmeno tali, se li guardi da un altro punto di vista.

 

boh io li metterei tra i problemi "fastidiosi"... sono problemi assolutamente risolvibili e sciocchi, che tuttavia ti prendono sempre del tempo e sono talmente idioti che la loro soluzione sarebbe banale... diciamo come avere una ferrari con degli interni verde pisello a pallini gialli e dei seggiolini di plastica scomodi... niente di vitale... però fa girare le balle no?   :Twisted Evil: 

Denotano IMHO scarsa attenzione verso l'usabilità del prodotto e dell'utente... 

Mi viene da pensare che gli stessi devel di portage non usino portage tutti i giorni, altrimenti si sarebbero sicuramente scontrati con tali problemi e li avrebbero risolti diverse versioni di portage fa   :Rolling Eyes: 

 *Quote:*   

> tuttavia questa è una bella discussione. sicuramente un buon punto di partenza per imparare qualcosa di più su portage e/o per chiedere delle nuove funzioni tramite bugzilla

 

Speriamo   :Smile: 

Se siamo in tanti a proporre qualcosa si può anche fare un post in inglese sul forum internazionale e vedere di catturare l'attenzione di qualcuno   :Rolling Eyes: 

@funkoolow

Si esatto... è questo quello che intendo   :Smile: 

Ok portage funziona e tutto quanto... ma giunto ormai dopo tanti anni alla versione 2.1 non dovrebbe avere parecchi meni spigoli?   :Rolling Eyes: 

Queste cose saranno pure ininfluenti sul funzionamento "globale" del sistema... però dopo un po' che ci perdi tempo sopra scassano davvero...  :Rolling Eyes: 

Globalmente portage mi da l'idea di un progetto ancora immaturo... un'eterna beta...   :Rolling Eyes: 

----------

## zolar czakl

1) Vedi se questo puo' essere un inizio (certo non con un server) https://forums.gentoo.org/viewtopic-p-3339221.html#3339221

2) Anche a me manca unclepine.

Domanda: visto che i files in portage sono in sola lettura (gli ebuild da personalizzare vanno da un'altra parte)

perche' non comprimerli (tipo man-pages, rimarrebbero facilmente consultabili)?

Esistono problemi concreti?

@funkoolow

In package.keywords dovrebbe andare solo il pacchetto da installare.

Le dipendenze dovrebbero essere smascherate in automatico (gli hardmasked magari sono un caso a parte).

Non risulterebbe piu' pulito anche il passaggio "a stabile" dei vari pacchetti? 

La presenza di versioni mascherate risulterebbe dinamicamente forzata solo dagli ebuild.

Andrebbe aggiunta la lettera M all'output di --pretend.

----------

## emix

 *zolar czakl wrote:*   

> 2) Anche a me manca unclepine.

 

Ma sono l'unico qui che non l'ha mai usato?  :Rolling Eyes: 

Onestamente non ho mai avuto grossi problemi di manutenzione (ma c'è da dire che con l'installazione e la rimozione del software sono di una precisione maniacale), anche se sono d'accordo sul fatto che portage potrebbe essere molto perfezionato.

Non ho mai fatto caso al comportamento di depclean con i pacchetti slotted (quelli non presenti nel world), ma devo dire che depclean non mi ha mai tradito... lo trovo un tool indispensabile, uno di quelli che rimpiango quando provo altre distribuzioni. Tornando agli slotted generalmente lancio un "equery list -d" e mi gestisco la cosa a mano. So che non è il massimo dell'automatismo, ma ormai ci sono così abituato che preferisco avere il controllo su ogni aspetto del sistema.

Una cosa che invece mi piacerebbe avere in portage è un'opzione di emerge che alla rimozione di un pacchetto rimuova anche i relativi file di configurazione. So che è possibile farlo con la variabile CONFIG_PROTECT, ma credo che un'opzioncina sarebbe molto più comoda.

----------

## cloc3

A me pare che portage preveda già la ristampa di certe informazioni alla fine dell'emerge.

Determinate informazioni, infatti, vengono stampate sia durante la compilazione del singolo ebuild, che al termine dell'emerge complessivo.

Penso quindi che questo sia un servizio disponibile per l'autore dell'ebuild.

Naturalmente, è necessario anche che tale risorsa sia utilizzata con equilibrio, altrimenti l'output finale, dopo una compilazione importante, potrebbe risultare chilometrico. Probabilmente sono gli stessi sviluppatori che adottano al riguardo una politica di autolimitazione, che talora, può risultare in contrasto con le nostre attese. La cosa migliore è redigirere sistematicamente l'output di emerge verso un file, in modo di essere in grado di rivedere, all'occorrenza, certi particolari.

È noto che il principale difetto di portage è determinato dalla mancanza di un controllo adeguato delle dipendenze inverse, ma questa è cosa nota. Da sempre. Il tentativo di xchris di fare ordine, si è purtroppo spento nonostante l'entusiasmo dell'autore, per manifesta mancanza di supporto, a al momento, non mi pare che esistano prospettive di ripresa del progetto.

Secondo me, il team di sviluppo ha rinunciato ad appoggiare e seguire quel progetto fin dal principio. Lo stesso xchris, ad un certo punto, ha cominciato a denunciare l'impossibilità tecnica di risolvere adeguatamente il problema (anche se, per la verità, in un certo periodo il suo script ha lavorato davvero bene) per motivi di complessità intrinseca ineliminabile.

Bisogna pensare che, in portage, la dipendenza inversa dipende dinamicamente dalle useflags, che un utente può modificare in qualunque momento e per qualsiasi ragione. In questo campo, secondo me, bisogna affidarsi principalmente alla prudenza e al buon senso dell'utente amministatore.

----------

## knefas

Riguardo al log, come un po' hanno gia' detto, se vuoi tutto in un unico file (diciamo) la soluzione e' piuttosto semplice, basta che in PORTAGE_ELOG_COMMAND metti uno scriptino che ti faccia il merge dei messaggi loggati sul file di log. Non ho mai provato, ma  potrebbe anche bastare qualcosa tipo 

```
echo '\${PACKAGE}' >> /var/log/loggenerale; cat '\${LOGFILE}' >> /var/log/loggenerale
```

----------

## Kernel78

se vuoi loggare tutte le info, i warnings e gli errors ma non ti interessa avere il log di TUTTO l'emerge di un pacchetto basta che metti 

```
PORTAGE_ELOG_CLASSES="info warn error"
```

 e poi decidi cosa farne con 

```
PORTAGE_ELOG_SYSTEM="save"
```

 ma per informazioni più dettagliate non posso che citare l'ultima GWN  *Quote:*   

> There are many more options like sending log messages via email. Please
> 
> check out make.conf.example for further information.

 

----------

## .:chrome:.

@Cazzantonio:

hai ragione: la man di emerge --prune non è molto rassicurante, ma se ben guardi non lo sono nemmeno le prime righe di output di emerge --depclean, e guardacaso lavorano entrambi nello stesso modo.

personalmente sono convinto che siano retaggi delle prime versioni di portage in cui queste funzioni erano implementate. anzi ti dirò di più: la man di portage contiene ormia informazioni vecchie ed inesatte riguardo depclean e prune

emerge --prune lo uso regolarmente per scremare i kernel, e non ho mai avuto problemi di alcun tipo (poi ovviamente può sempre capitare la botta di sfiga e una volta ogni tanto possono fare danni, ma quella, come detto, è davvero sfiga

@emix:

no. anche io non l'ho mai usato. i tool di portage, secondo me non lavorano così male, e non mi fanno sentire la mancanza di niente

----------

## X-Drum

 *Cazzantonio wrote:*   

> Intendiamoci... a me piace gento...  
> 
> 

 

anche a me piace gentoo

----------

## Cazzantonio

 *cloc3 wrote:*   

> A me pare che portage preveda già la ristampa di certe informazioni alla fine dell'emerge.
> 
> Determinate informazioni, infatti, vengono stampate sia durante la compilazione del singolo ebuild, che al termine dell'emerge complessivo.

 

Si alla fine ti dice che devi lanciare etc-update... grazie mille   :Smile: 

preferirei che mi stampasse gli ewarn e gli einfo visto che talvolta (tipo un pacchetto su 100) sono discretamente importanti...

Se uno deve installare 100 pacchetti mica può farlo uno per uno... e redirigere l'output in un file per riguardarselo è terribilmente più faticoso che leggere l'ebuild   :Smile: 

Faccio comunque un esempio in cui anche leggere l'ebuild non aiuta:

openldap: quando viene aggiornato fa una ricerca delle vecchie librerie e richiede di fare un revdep rebuild specifico per ogni libreria vecchia prima di rimuoverla (il revdep-rebuild globale non aiuta)

Se stai aggiornando openldap insieme ad altri pacchetti è automatico che tu ti perda tale avviso... a questo punto mi chiedo... ha senso metterlo?   :Rolling Eyes:  Ha senso mettere un avviso se non è leggibile?   :Rolling Eyes: 

Semmai ci dovrebbe essere un opzione per stampare su file gli avvisi e il nuovo portage va nella direzione giusta... tuttavia è ancora poco usabile visto che nel caso i pacchetti da emergere siano tanti ti tocca andare a guardare file per file quello che ha scritto... continuo a dire che stampare tutto alla fine dell'emersione (in forma comprensibile) sarebbe di gran lunga meglio   :Rolling Eyes: 

 *Quote:*   

> Naturalmente, è necessario anche che tale risorsa sia utilizzata con equilibrio, altrimenti l'output finale, dopo una compilazione importante, potrebbe risultare chilometrico. 

 

Parto dal presupposto che se ti sei disturbato a mettere un avvisto allora sia importante leggerlo!

Altrimenti come già detto te lo potevi risparmiare!   :Twisted Evil: 

 *Quote:*   

> È noto che il principale difetto di portage è determinato dalla mancanza di un controllo adeguato delle dipendenze inverse, ma questa è cosa nota. Da sempre. Il tentativo di xchris di fare ordine, si è purtroppo spento nonostante l'entusiasmo dell'autore, per manifesta mancanza di supporto, a al momento, non mi pare che esistano prospettive di ripresa del progetto.

 

E qua non mi sento di incolpare altri che i devel di portage   :Evil or Very Mad: 

 *Quote:*   

> Lo stesso xchris, ad un certo punto, ha cominciato a denunciare l'impossibilità tecnica di risolvere adeguatamente il problema (anche se, per la verità, in un certo periodo il suo script ha lavorato davvero bene) per motivi di complessità intrinseca ineliminabile.

 

Il fatto è che unclepine non usa le funzioni integrate in portage. Se fosse supportato dal team gentoo in via ufficiale ci vorrebbe poco ad aggiornarlo ad ogni nuova relase di portage. Il fatto che ora non funzioni con portage-2.1 è imputabile solo al fatto che xchris ha da fare è non è molto partecipe del forum gentoo. (e questa cosa ovviamente non è colpa sua... semmai è un merito averci supportato e/o sopportato finora   :Smile:  )

 *Quote:*   

> In questo campo, secondo me, bisogna affidarsi principalmente alla prudenza e al buon senso dell'utente amministatore.

 

No. L'esempio di unclepine ci mostra come con un piccolo sforzo si possa produrre un tool in grado di fare tutto quello che si chiede...

 *Kernel78 wrote:*   

> se vuoi loggare tutte le info, i warnings e gli errors ma non ti interessa avere il log di TUTTO l'emerge di un pacchetto basta che metti 
> 
> ```
> PORTAGE_ELOG_CLASSES="info warn error"
> ```
> ...

 

Si lo so... tuttavia si ritorna al discorso di prima... si può fare tutto, solo che è un pacco clamoroso.

Ti pare che posso stare a spedirmi gli elog via mail quando basterebbe stamparli alla fine di un emerge. Anche senza elog potevo comunque leggermi l'ebuild... solo non mi pare una soluzione elegante degna di un gestore di pacchetti efficente.

Comunque anche il fatto che ci abbiano pensato solo dalla versione 2.1 in poi è indicativo della loro attenzione verso questi "particolari".

 *k.gothmog wrote:*   

> @Cazzantonio:
> 
> hai ragione: la man di emerge --prune non è molto rassicurante, ma se ben guardi non lo sono nemmeno le prime righe di output di emerge --depclean, e guardacaso lavorano entrambi nello stesso modo.

 

No mentre emerge --depclean funziona (a parte il problema con gli slotted) emerge --prune ti elimina tutte le versioni di un pacchetto tranne la più recente... se un pacchetto è slotted c'è un motivo... probabilmente è dipendenza di qualcosa anche la versione vecchia.

Comunque resta il fatto che non c'è un modo efficente per sapere le dipendenze di un pacchetto. equery funziona sulla maggior parte dei pacchetti ma non su tutti... ora sinceramente mi sarei aspettato che un tool fondamentale come equery dovesse funzionare alla perfezione... non "più o meno"   :Evil or Very Mad: 

----------

## .:chrome:.

 *Cazzantonio wrote:*   

> No mentre emerge --depclean funziona (a parte il problema con gli slotted) emerge --prune ti elimina tutte le versioni di un pacchetto tranne la più recente... se un pacchetto è slotted c'è un motivo... probabilmente è dipendenza di qualcosa anche la versione vecchia.

 

hai ragione. ho provato ed è proprio così

direi che è la un'ottimo motivo per cui aprire il bug per un'enhancement

----------

## Cazzantonio

Io ho provato a vedere quali bug ci fossero aperti per equery...   :Smile:  fatti un giro e guarda   :Wink: 

Comunque per emerge --prune non mi sembra ci siano bug aperti   :Rolling Eyes:  Aprilo pure   :Wink: 

----------

## zolar czakl

Sempre in tema di log.

Non si potrebbe utilizzare

```
PORTAGE_ELOG_SYSTEM="syslog"
```

ed inserire un nuovo modulo in portage-bashrc-ng che faccia un riassunto alla fine dell'emerge?

E' solo un idea ed e' sempre una soluzione esterna.

----------

## .:chrome:.

prima di aprire nuovi bug, vorrei analizzare per bene la situazione, data la fottuta tendenza che hanno i bug-wranglers a non leggere con attenzione quello che la gente scrive. cani! dovrebbero aprire un bug su di loro!

rileggendo bene man portage sembra che emerge --prune faccia esattamente quello che dovrebbe. peccato si tratti di qualcosa senza senso, perché a ben pensarci non mi viene in mente una situazione in cui quella funzione potrebbe essere comoda (a parte il kernel).

oltretutto la man dice che rimuove tutte le versioni di un pacchetto tranne l'ultima, ma per ultima intende non l'ultima disponibile, bensì l'ultima che è stata installata (esempio: ho installato gtk+-1.2 e poi ho fatto emerge --prume. mi ha disinstallato gtk+-2. :Cool: , e questo è davvero privo di senso.

penso che il vero problema sia in depclean, che non è proprio capace di gestire i pacchetti slotted e li salta a piedi pari.

ora quello che mi chiedo è se sia possibile rimuovere un pacchetto slotted che non serve più, o meglio se sia possibile capire che non serve più

----------

## xlyz

scusasse cazzantanio, ma se ricordo bene (utlimamente apto invece di emergere  :Wink:  ) tutti i vari warning sono evidenziati dalla classica coppia di asteriski. a questo punto cosa ti impedisce di greppare lo stdout per vedere/salvare solo i messaggi?

----------

## .:chrome:.

 *xlyz wrote:*   

> utlimamente apto invece di emergere

 

oddio, un debianista!!!

mi è scaduto il vaccino!   :Very Happy: 

scherzi a parte, c'è un'altra cosa che sto notando in questi giorni...

è possibile creare, in /etc/portage, invece che il file package.keywords una directory omonima, ed in essa porre dei files con la sintassi di package.keywords. perché fare ciò? per un mero motivo di ordine. in questo modo ho il file con le keywords di gnome-2.14, quello di gcc-4.1, ecc...

il problema è che eix non gestisce questa cosa, e mostra tutto come se fosse masked. ci sarebbe da aprire un big su questo, ma ho visto che eix è un progetto esterno, con la sua home page separata dal sito di gentoo, ecc... qualcuno ne sa qualcosa?

----------

## Kernel78

 *Cazzantonio wrote:*   

> 
> 
>  *Kernel78 wrote:*   se vuoi loggare tutte le info, i warnings e gli errors ma non ti interessa avere il log di TUTTO l'emerge di un pacchetto basta che metti 
> 
> ```
> ...

 

... e chi ha detto di spedirtelo via email, con elog io me li salvo in tanti comodi file e me li spulcio con calma.

D'altronde a me sembrerebbe scomodissima la tua soluzione, visto che io emergo da remoto usando sessioni di screen all'interno di ssh o mi metto il buffer di screen a dimensioni enormi o rischio sempre di perdermi qualche informazione quando mi ricollego per controllare se ha finito. I file di elog invece mi rimangono e posso leggermeli con calma, inviarmeli per email o incanalarli in syslog o farci quello che più mi aggrada in classico stile gentoo  :Wink: 

----------

## Kernel78

 *k.gothmog wrote:*   

> è possibile creare, in /etc/portage, invece che il file package.keywords una directory omonima, ed in essa porre dei files con la sintassi di package.keywords. perché fare ciò? per un mero motivo di ordine. in questo modo ho il file con le keywords di gnome-2.14, quello di gcc-4.1, ecc...
> 
> il problema è che eix non gestisce questa cosa, e mostra tutto come se fosse masked. ci sarebbe da aprire un big su questo, 

 

Questa funzionalità stavo iniziando a guardarla e per risolvere il problema di eix pensavo di mettere in cron uno script che ogni X faccia un cat di tutti i *.keywords in un package.keywords in modo che eix possa dare risultati corretti, ovviamente si tratta di un workaround e ancora non l'ho provato ma mi sembra un metodo semplice per ovviare temporaneamente al problema ...

Adesso lo provo ...

/EDIT:Ovviamente non potendo esistere un file e una directory con lo stesso nome la directory dovrebbe trovarsi altrove ...

----------

## cloc3

 *Cazzantonio wrote:*   

>  *cloc3 wrote:*   A me pare che portage preveda già la ristampa di certe informazioni alla fine dell'emerge.
> 
> Determinate informazioni, infatti, vengono stampate sia durante la compilazione del singolo ebuild, che al termine dell'emerge complessivo. 
> 
> Si alla fine ti dice che devi lanciare etc-update... grazie mille  
> ...

 

Effettivamente, ho provato a controllare, e devo ammettere che dicevo una cosa inesatta.

La mia convinzione era che esistesse una distinzione sintattica tra i comandi einfo, ewarn ed eerror relativa anche al comportamento che discutiamo, ma non è così.

A me pareva di averlo verificato tempo addietro con il pacchetto expat-2.0.

Mi chiedo se per caso ciò non dipenda dalla versione di portage, perché allora avevo un portage stabile, mentre adesso ce l'ho sperimentale.

Probabilmente la cosa migliore sarebbe richiedere una modifica ad emerge su bugzilla e vedere cosa rispondono.

Quanto a xchris, ho descritto una situazione di fatto nel modo più neutro che mi fosse possibile. Anche io sono dispiaciuto di come stia evolvendo la situazione, ma non ne conosco i motivi. Le librerie di portage mi sembrano una ragione insufficiente. Se quello di xchris era un impianto funzionale, se ne sarebbe potuta ugualmente recepire la struttura.

Il fatto che ora non funzioni con portage-2.1 dipende proprio dal fatto che non è stato supportato dal team ufficiale - quali che siano le ragioni. Non è possibile mantenere un progetto così delicato e strategico sulle spalle di una sola persona.

In ogni caso, nonostante gli appunti che stiamo facendo, ritengo che portage abbia fatto dei progressi significativi negli ultimi tempi, diventando più veloce (ricordate gli `emerge metadata` di sei mesi fa?) e meglio suportato dalle funzioni di gentoolkit. A parte le dipendenze, equery è un ottimo programma. Il controllo dei file installati è molto migliore rispetto a tempo addietro. Un semplice 'equery b nomefile' mi ha risolto spesso parecchi problemi e mi fa credere che il controllo del sistema sia migliore che in precedenza. È stato modificato in profondità tutto il database e questo ha richiesto una quantità di scelte e una programmazione degli impegni, di cui sicuramente non conosciamo molti aspetti. Sono sicuro che anche il problema delle dipendenze inverse troverà a suo tempo una composizione.

----------

## .:chrome:.

 *Kernel78 wrote:*   

> Ovviamente non potendo esistere un file e una directory con lo stesso nome la directory dovrebbe trovarsi altrove ...

 

ti sei risposto da solo: eix deve leggere package.keywords. se è un file lo legge e basta, e se è una directory la legge in modo oterativo. questo dovrebbe essere il funzionamento corretto

----------

## Cazzantonio

 *k.gothmog wrote:*   

> penso che il vero problema sia in depclean, che non è proprio capace di gestire i pacchetti slotted e li salta a piedi pari.ora quello che mi chiedo è se sia possibile rimuovere un pacchetto slotted che non serve più, o meglio se sia possibile capire che non serve più

 

Sicuramente non con equery   :Smile: 

quindi direi che per ora i problemi sono sia depclean che equery   :Wink: 

 *xlyz wrote:*   

> scusasse cazzantanio, ma se ricordo bene (utlimamente apto invece di emergere  ) tutti i vari warning sono evidenziati dalla classica coppia di asteriski. a questo punto cosa ti impedisce di greppare lo stdout per vedere/salvare solo i messaggi?

 

Beh è terribilmente scomodo e non si capisce nulla...   :Smile: 

Comunque gli elog sono "in qualche modo" accessibili... ci sono diverse cose (anche il bashrc) che si possono implementare per leggerli...

Solo mi stupisce il fatto che portage non lo faccia nativamente e in maniera efficente   :Smile:   (per ora la cosa che ci si avvicina di più mi sembra quella di passare ad syslog tutto quanto e loggarlo in un file...    :Rolling Eyes:  ma devi saperlo fare... un utente medio dubito sappia come configurare syslog   :Rolling Eyes:  )

 *Kernel78 wrote:*   

> D'altronde a me sembrerebbe scomodissima la tua soluzione, visto che io emergo da remoto usando sessioni di screen all'interno di ssh o mi metto il buffer di screen a dimensioni enormi o rischio sempre di perdermi qualche informazione quando mi ricollego per controllare se ha finito. I file di elog invece mi rimangono e posso leggermeli con calma, inviarmeli per email o incanalarli in syslog o farci quello che più mi aggrada in classico stile gentoo 

 

bene e lungi da me l'idea di limitare la tua libertà in questo senso   :Smile: 

Sicuramente se non ci fosse il modo di loggare gli elog sarebbe un utile feature da richiedere... tuttavia per un utente medio (che non aggiorna il sistema via ssh con screen) forse stamparli in fondo all'emerge continuerebbe ad essere un'ottima idea   :Smile: 

Mica chiedo che li stampi sempre... magari solo se emergo con --verbose   :Wink: 

 *cloc3 wrote:*   

> In ogni caso, nonostante gli appunti che stiamo facendo, ritengo che portage abbia fatto dei progressi significativi negli ultimi tempi

 

Ma infatti non voglio fare una critica totale a portage   :Smile: 

Portage funziona bene e lo ritengo uno dei migliori packet-manager in circolazione... solo il fatto che presenti questi difetti fastidiosi e facilmente risolvibili mi riempie di stupore   :Shocked: 

Possibile che si perda tempo a migliorare la gestione dei metadata (cosa importante) e non si abbia un minuto per risolvere questi problemi minori che affliggono da sempre portage?   :Shocked: 

----------

## Cazzantonio

Se volete fare un confronto tra l'output di equery e quello di unclepine provate questo script.

Non fa altro che invocare equery depends per ogni paccheto installato e vedere se non è dipendenza di niente.

Fa un controllo sia usando pacchetto+versione che senza versione e sputa fuori quanto risultato "unlinked" in entrambi i casi.

Guarda anche tra i pacchetti slotted e cerca di capire quali vesioni sono necessarie o meno. Segnala per quali pacchetti slotted non è stato possibile capire niente e quali siano invece i pacchetti slotted citati in world (per cui è necessario un controllo manuale).

Il codice non è bellissimo ma serve per rendersi conto della differenza profonda tra l'output di unclepine e il funzionamento "buggato" di equery   :Smile:  (ci mette anche 10 minuti abbondanti in più   :Rolling Eyes:  )

Se così non fosse basterebbe questo per trovare la spazzatura di sistema e non avremmo bisogno di unclepine   :Rolling Eyes:  (a parte la funzione unclepine -sw che secondo me è fondamentale per "ripulire" il proprio world   :Smile:  )

```
#!/bin/bash

#Dir dove loggare i file temporanei

DIR_TEMPORANEA=/tmp/equery_orphan

test -d $DIR_TEMPORANEA && rm $DIR_TEMPORANEA -rf

mkdir $DIR_TEMPORANEA

######################CALCOLO DEI PACCHETTI TOTALI##############################

equery list |grep "/" > $DIR_TEMPORANEA/pacchetti_totali

################################################################################

######################CALCOLO DEI PACCHETTI IN WORLD############################

cp /var/lib/portage/world $DIR_TEMPORANEA/pacchetti_mondo

################################################################################

######################CALCOLO DEI PACCHETTI IN SYSTEM###########################

cd /etc/make.profile/

cat /etc/make.profile/packages |grep -v "#" > $DIR_TEMPORANEA/pacchetti_sistema

while test -e parent

do

  cd -P `cat parent`

  cat packages |grep -v "#" >> /$DIR_TEMPORANEA/pacchetti_sistema

done

cat $DIR_TEMPORANEA/pacchetti_sistema |sort|uniq|cut -d"*" -f2|cut -d">" -f2|cut -d"=" -f2 > $DIR_TEMPORANEA/pacchetti_sistema2

mv $DIR_TEMPORANEA/pacchetti_sistema2 $DIR_TEMPORANEA/pacchetti_sistema -f

cd ~

################################################################################

######################COMPUTO DEI PACCHETTI INSTALLATI PRESENTI IN WORLD########

for i in `cat $DIR_TEMPORANEA/pacchetti_mondo`

do

grep $i $DIR_TEMPORANEA/pacchetti_totali >> $DIR_TEMPORANEA/pacchetti_world

done

################################################################################

######################COMPUTO DEI PACCHETTI INSTALLATI PRESENTI IN SYSTEM#######

for i in `cat $DIR_TEMPORANEA/pacchetti_sistema`

do

grep $i $DIR_TEMPORANEA/pacchetti_totali >> $DIR_TEMPORANEA/pacchetti_system

done

################################################################################

test -e $DIR_TEMPORANEA/pacchetti_mondo && rm $DIR_TEMPORANEA/pacchetti_mondo -f

test -e $DIR_TEMPORANEA/pacchetti_sistema && rm $DIR_TEMPORANEA/pacchetti_sistema -f

######################PRIMA RICERCA CON EQUERY DEI PACCHETTI ORFANI#############

#La prima ricerca usa anche il numero di versione che stranamente non sempre 

#equery accetta... ovvero segna come orfano un pacchetto+versione mentre se 

#invocato solo con nome del pacchetto segnala correttamente la dipendenza...

#per sicurezza si fa la ricerca in entrambi i modi

for i in `cat $DIR_TEMPORANEA/pacchetti_totali`

do

  if [ `cat $DIR_TEMPORANEA/pacchetti_world |grep $i|wc -l` -eq 0 ] && [ `cat $DIR_TEMPORANEA/pacchetti_system |grep $i|wc -l` -eq 0 ]

  then

    if [ `equery depends $i |wc -l` -ge 1 ]

    then 

      echo $i >> $DIR_TEMPORANEA/pacchetti_dipendenze

    else

      echo $i non è dipendenza di niente al primo filtraggio

      echo $i >> $DIR_TEMPORANEA/pacchetti_orfani_1

    fi

  fi

done

echo Finito primo filtraggio

################################################################################

######################SECONDA RICERCA CON EQUERY DEI PACCHETTI ORFANI###########

#Questa ricerca prende in pasto la lista della prima ed effettua una ricerca

#senza considerare il numero della versione del pacchetto

for i in `cat $DIR_TEMPORANEA/pacchetti_orfani_1`

do

  PIPPO=$(echo "$i" | sed -e 's/-[0-9]/*/g' | cut -d"*" -f1 )

  if [ `equery depends $PIPPO |wc -l` -ge 1 ]

  then

    echo $i >> $DIR_TEMPORANEA/pacchetti_dipendenze

  else

    echo $i non è dipendenza di niente al secondo filtraggio

    echo $i >> $DIR_TEMPORANEA/pacchetti_orfani_2

  fi

done

echo Finito secondo filtraggio

################################################################################

######################RICERCA TRA I PACCHETTI SLOTTED###########################

#Le precedenti ricerce di fatto ignoravano (grazie al secondo filtraggio) i 

#pacchetti slotted (ovvero i pacchetti di cui sono installate versioni multiple).

#Si rimedia al problema ricercando nuovamente tra i pacchetti slotted e mettendo 

#eventualmente alla luce eventuali incongruenze (visto che equery sembra fare 

#differenza tra un nomepacchetto con o senza versione...

equery list -d > $DIR_TEMPORANEA/pacchetti_slotted

for i in `cat $DIR_TEMPORANEA/pacchetti_slotted | sed -e 's/-[0-9]/*/g' | cut -d"*" -f1 |sort|uniq`

do

  grep $i $DIR_TEMPORANEA/pacchetti_world >> $DIR_TEMPORANEA/pacchetti_slotted_world

  if [ `equery depends $i |wc -l` -eq 0 ] 

  then

    [ `grep $i $DIR_TEMPORANEA/pacchetti_world|wc -l` -eq 0 ] && echo $i >> $DIR_TEMPORANEA/pacchetti_slotted_rimuovere

  fi

  

  for j in `cat $DIR_TEMPORANEA/pacchetti_slotted |grep $i`

  do

    if [ `equery depends $j |wc -l` -eq 0 ]

    then

      [ `grep $j $DIR_TEMPORANEA/pacchetti_slotted_world|wc -l` -eq 0 ] && echo $j >> $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2

    fi

  done

  

  CONTO1=$(cat $DIR_TEMPORANEA/pacchetti_slotted |grep $i|wc -l)

  if test -e $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2

  then

  CONTO2=$(cat $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2|wc -l)

  else

  CONTO2=0

  fi

  

  if [ $CONTO1 -eq $CONTO2 ] && [ `equery depends $i |wc -l` -ge 1 ]

  then

    cat $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2 >> $DIR_TEMPORANEA/pacchetti_slotted_problem

  else

    if test -e $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2

    then

    cat $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2 >> $DIR_TEMPORANEA/pacchetti_slotted_rimuovere

    fi

  fi    

  test -e $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2 && rm $DIR_TEMPORANEA/pacchetti_slotted_rimuovere2 -f

done

echo ""

echo ""

echo ""

echo "Pacchetti orfani esclusi gli slotted:"

cat $DIR_TEMPORANEA/pacchetti_orfani_2

echo ""

echo ""

echo ""

echo "I seguenti pacchetti sono slotted orfani:"

cat $DIR_TEMPORANEA/pacchetti_slotted_rimuovere

echo ""

echo ""

echo "I seguenti pacchetti sono slotted in world:"

cat $DIR_TEMPORANEA/pacchetti_slotted_world

echo ""

echo ""

echo "I seguenti pacchetti sono slotted problematici:"

cat $DIR_TEMPORANEA/pacchetti_slotted_problem

echo ""

echo ""

test -d $DIR_TEMPORANEA && rm $DIR_TEMPORANEA -rf
```

A me da questi pacchetti unlinked:

```
Pacchetti orfani esclusi gli slotted:

app-admin/fam-2.7.0-r4

app-cdr/cdrtools-2.01.01_alpha07

dev-perl/perl-tk-804.027

dev-util/indent-2.2.9-r2

mail-client/mailx-8.1.2.20040524-r1

media-libs/libdc1394-1.2.1

net-libs/libgsasl-0.2.4

sci-visualization/gnuplot-4.0-r1

sys-apps/eject-2.1.0-r1

sys-apps/less-394

sys-apps/module-init-tools-3.2.1

I seguenti pacchetti sono slotted orfani:

sys-devel/automake-1.4_p6

sys-devel/automake-1.5

sys-devel/automake-1.6.3

sys-libs/db-1.85-r2

I seguenti pacchetti sono slotted in world:

app-crypt/gnupg-1.4.2.2

app-crypt/gnupg-1.9.20-r3

I seguenti pacchetti sono slotted problematici:

dev-libs/glib-1.2.10-r5

dev-libs/glib-2.8.6

gnome-base/orbit-0.5.17-r1

gnome-base/orbit-2.12.5

x11-libs/gtk+-1.2.10-r11

x11-libs/gtk+-2.8.12

x11-libs/gtkglarea-1.2.3-r1

x11-libs/gtkglarea-1.99.0
```

mentre emerge -pv --depclean e unclepine -u non me ne vedono nemmeno uno   :Smile: 

Siete ancora convinti che equery depends funzioni a dovere?   :Wink: 

Giusto per chiarezza gli slotted problematici sono pacchetti che risultano dipendenti di qualcosa senza specificare il numero di versione ma poi ogni varia versione sembra "unlinked"   :Shocked: 

----------

## codadilupo

dico anche la mia  :Wink: 

richieste:

1) ELOG a fine installazione

2) portage ristretto (posso buttare disco in file di testo ???)

3) unclepine!

risposte: 

1) mi accontento di un ELOG che non mi logga tutto... magari un tool che mi legga gl'ewarn direttamente dagl'ebuild (tipo una opzione in piu', che copia gl'ewarn in un file temporaneo durante l'installazione, e me li legge - previa domanda, alla fine ( enotice ?).

2) se portage stesse sui server, e emerge mi scaricasse di volta in in volta gl'ebuild necessari, aumenterebbero le chiamate ai server, ma i sync si ridurrebbero a scaricare un file di indice

3) ... boh!  :Wink: 

Coda

----------

## .:chrome:.

@codadilupo:

2) non ho capito

----------

## comio

 *k.gothmog wrote:*   

> @codadilupo:
> 
> 2) non ho capito

 

intende dire che non è normale avere 500Mega di directory /usr/portage...

Magari dovrebbero pensare a tecniche di compresione (tipo squashfs) oppure a gzippare le directory. Non credo che ci sarebbero troppi problemi a gzippare le singole directory in /usr/portage/.

Lo so che ci sono mille post... ma sono work-around.

ciao

----------

## federico

 *codadilupo wrote:*   

> 
> 
> 2) portage ristretto (posso buttare disco in file di testo ???)
> 
> 2) se portage stesse sui server, e emerge mi scaricasse di volta in in volta gl'ebuild necessari, aumenterebbero le chiamate 

 

Io sono un fautore di questo modo di gestire i file, e tanto per iniziare penso che il sistema attuale di gestione degli ebuild sia fatto male. 

Nella mia ottica si potrebbe avere sulla macchina un database di tutti i pacchetti che e' possibile installare, magari fatto con sqlite in modo che non ho necessita' di avere un serversql sul pc. La macchina synca il database modificando solo quello che e' relamente variato e lasciando perdere il resto, e questo database dovrebbe contenere le informaziioni base sui pacchetti (descrizione, versione, dimensione, grado di stabilita e cose del genere)

Quando decido di emergere un pacchetto il mio pc legge il database, interroga un server che contiene tutti gli ebuild e scarica l'ebuild che mi serve(e relative dipendenze), fa il digest e emerge.

Ottimizzato al massimo no ?  :Smile: 

Federico

----------

## knefas

Qualcuno ha provato (su un sistema testing, ovvio) se Paludis sia interessante/risolva questi problemi?

----------

## comio

 *Quote:*   

> 
> 
> Io sono un fautore di questo modo di gestire i file, e tanto per iniziare penso che il sistema attuale di gestione degli ebuild sia fatto male. 
> 
> Nella mia ottica si potrebbe avere sulla macchina un database di tutti i pacchetti che e' possibile installare, magari fatto con sqlite in modo che non ho necessita' di avere un serversql sul pc. La macchina synca il database modificando solo quello che e' relamente variato e lasciando perdere il resto, e questo database dovrebbe contenere le informaziioni base sui pacchetti (descrizione, versione, dimensione, grado di stabilita e cose del genere)
> ...

 

Io credo invece che avere gli ebuild il locale non sia male. Perché permette di avere visione di quello che si può installare. In ogni caso, avere gli ebuild in remoto sarebbe un problema per ogni emerge, dato che avresti n-mila interrogazioni con i server remoti... e dato che la banda si paga, non mi pare una cosa ottimizzata.

Preferisco invece avere la possibilità di zippare le directory (facoltative). Emerge/Portage non dovrebbe fare altro che unzippare analizzare i file e quindi cancellare la directory alla fine.

Mi sembra una soluzione più semplice di un fs compresso (che richiede il kernel compilato ad hoc). Ovviamente bisogna affiancare il tutto da un buon sistema di indicizzazione per evitare colli di bottiglia tremendi (in fondo la compressione risparmia spazio ma non tempo).

Ovviamente IMHO.

Ciao

----------

## comio

 *comio wrote:*   

> 
> 
> intende dire che non è normale avere 500Mega di directory /usr/portage...
> 
> Magari dovrebbero pensare a tecniche di compresione (tipo squashfs) oppure a gzippare le directory. Non credo che ci sarebbero troppi problemi a gzippare le singole directory in /usr/portage/.
> ...

 

Per la cronaca, targzippando per directory ottengo 37Mega in tutto (contro i 500 non compressi)...

ciao

----------

## .:deadhead:.

Io ho implementato con soddisfazione questa soluzione: evito il rsync di parti dell'albero, filtrandole. Questo riesce bene specie su macchine server, dove sai che di X e dei vari WM non avrai bisogno. Questo alleggerisce il rsync e la creazione di cache nonchè la ricerca su di esso.

----------

## federico

 *.:deadhead:. wrote:*   

> Io ho implementato con soddisfazione questa soluzione: evito il rsync di parti dell'albero, filtrandole. Questo riesce bene specie su macchine server, dove sai che di X e dei vari WM non avrai bisogno. Questo alleggerisce il rsync e la creazione di cache nonchè la ricerca su di esso.

 

Noi non vogliamo rinunciare a nulla  :Smile: 

Comio hai ragione se solleviamo un problema di banda, se fosse possibile uno zip automatico il problema di SPAZIO su disco sarebbe risolto, ma non sarebbe comunque risolto il problema di tempo e indicizzazione, che verrebbe piuttosto allungato (A me comunque occupano 700 mega, non 500, gli ebuild).

----------

## !equilibrium

 *comio wrote:*   

> Per la cronaca, targzippando per directory ottengo 37Mega in tutto (contro i 500 non compressi)...

 

uhmmm io ho 160Mb (ad arrotondare per eccesso!!) non compressi, filesystem puro:

```
 du -sbh /usr/portage/

152M    /usr/portage/

```

ed è così su tutte le macchine, sui server arrivo a malapena a 60MB perchè faccio come fa @deadhead, cioè filtro le dir di portage che non userò mai in produzione (ovvero tutto X, games, WM ecc ecc); sinceramente non credo che al giorno d'oggi, 150/160Mb di spazio siano un problema.

----------

## comio

 *!equilibrium wrote:*   

>  *comio wrote:*   Per la cronaca, targzippando per directory ottengo 37Mega in tutto (contro i 500 non compressi)... 
> 
> uhmmm io ho 160Mb (ad arrotondare per eccesso!!) non compressi, filesystem puro:
> 
> ```
> ...

 

Io uso xfs che non è molto gentile con i file piccoli...  :Very Happy: 

ciao

----------

## !equilibrium

 *comio wrote:*   

> Io uso xfs che non è molto gentile con i file piccoli... 

 

ehmmm io uso solo XFS, fai il conto tu...  :Wink:  eppure....

p.s.: e si che non è difficile formattare con cluster da 512bit, e la cosa comunque è filesystem indipendente, lo stesso (lieve differenza di +/-10%) risultato si otterrebbe anche con ext2/3 e reiserfs3, mentre per reiserfs4 i clusters da 512bit sono di default.

----------

## !equilibrium

 *federico wrote:*   

> Nella mia ottica si potrebbe avere sulla macchina un database di tutti i pacchetti che e' possibile installare, magari fatto con sqlite in modo che non ho necessita' di avere un serversql sul pc. La macchina synca il database modificando solo quello che e' relamente variato e lasciando perdere il resto, e questo database dovrebbe contenere le informaziioni base sui pacchetti (descrizione, versione, dimensione, grado di stabilita e cose del genere)
> 
> Quando decido di emergere un pacchetto il mio pc legge il database, interroga un server che contiene tutti gli ebuild e scarica l'ebuild che mi serve(e relative dipendenze), fa il digest e emerge.

 

ehmmmm arrivi un po in ritardo:

http://thread.gmane.org/gmane.linux.gentoo.server/3352

http://thread.gmane.org/gmane.linux.gentoo.server/3373

ci stanno già lavorando.

----------

## federico

 *!equilibrium wrote:*   

>  *comio wrote:*   Per la cronaca, targzippando per directory ottengo 37Mega in tutto (contro i 500 non compressi)... 
> 
> uhmmm io ho 160Mb (ad arrotondare per eccesso!!) non compressi, filesystem puro:
> 
> ```
> ...

 

Ma io ne ho 700 di mega...

----------

## !equilibrium

 *federico wrote:*   

> Ma io ne ho 700 di mega...

 

l'ho spiegato sopra (e in altri thread del forum) basta formattare correttamente il filesystem con clusters da 512bit e risparmi un sacco di spazio sul portage. ne guadagna in velocità anche il processo di sync.

----------

## Dr.Dran

Ciauz eh eh eh

Dopo un pò di tempo mi faccio vivo eh eh eh

Bene non capisco questa diffidenza nel voler accettare che il filesystem possa gestire cluster piccoli da 512byte, insomma strano, e' una cosa che ho sperimentato circa un annetto fa e su cui ho fatto dei test con iozone e debbo dire che le performance non calano in termini sensibili, anzi di guadagno ho che posso inserire + files anche piccoli e perdo meno spazio allocabile... Insomma non e' difficile capirlo.

P.S. !equilibrium tieni duro, hai un'altro utente che ha la tua stessa configurazione e che e' felice di avere in 150 megabyte Portage  :Very Happy:  (ovviameente completo senza potare directory o altro eh eh eh)

P.P.S. Per chi non l'avesse capito ho XFS pure io e debbo dire che sia sulla mia workstation che sul mio laptop che sul serverino si comporta egregiamente ed è stabile. Ho provato per esempio a utilizzare reiserfs3 con cluster da 512byte, ma copiando un file di 4 Mbyte andava in segfault...mmm non mi sembra bello  :Very Happy:  :Very Happy:  :Very Happy: 

----------

## federico

 *!equilibrium wrote:*   

>  *federico wrote:*   Ma io ne ho 700 di mega... 
> 
> l'ho spiegato sopra (e in altri thread del forum) basta formattare correttamente il filesystem con clusters da 512bit e risparmi un sacco di spazio sul portage. ne guadagna in velocità anche il processo di sync.

 

A bhe ora proprio e' tardi per farlo, certo che se sul manuale ci fosse qualcosa a riguardo...

----------

## Dr.Dran

 *federico wrote:*   

> A bhe ora proprio e' tardi per farlo, certo che se sul manuale ci fosse qualcosa a riguardo...

 

Beh e chi lo dice.... Stage4 e poi via si ripartiziona e poi si ributta su tutto il sistema.... problemi = 0  :Very Happy: 

P.S: In questo modo uno si abitua pure a fare i backup eh eh eh quindi si unisce l'utila (backup) al dilettevole (sperimentazione)  :Very Happy: 

----------

## darkmanPPT

uao... 

non mi ero mai accorto di queste cose.

a me portage mi pareva una gran bella cosa!

....  :Embarassed:  si vede che non son un gran linuxiano....

----------

## emix

 *federico wrote:*   

> Ma io ne ho 700 di mega...

 

Be', ma voi contate pure i distfiles?

----------

## emix

 *federico wrote:*   

> Quando decido di emergere un pacchetto il mio pc legge il database, interroga un server che contiene tutti gli ebuild e scarica l'ebuild che mi serve(e relative dipendenze), fa il digest e emerge.

 

In questo modo però si dovrebbero tenere a disposizione tutte le versioni degli ebuild (anche quelli obsoleti) nel caso in cui il database locale dei pacchetti non sia sincronizzato con il server.

----------

## comio

 *emix wrote:*   

>  *federico wrote:*   Ma io ne ho 700 di mega... 
> 
> Be', ma voi contate pure i distfiles?

 

no. E' tutta questione di cluster. Io uso cluster da 4k (impostazione di default), mentre altri usano cluster da 512... in media, si ha un risparmio di 3 volte circa.

ciao

luigi

----------

## emix

 *comio wrote:*   

> no. E' tutta questione di cluster.

 

Siccome ho visto che usavate questo comando:

```
 du -sbh /usr/portage/ 

 152M    /usr/portage/
```

E siccome quel comando va a pescare anche nella directory dei distfiles  :Rolling Eyes: 

----------

## comio

 *emix wrote:*   

>  *comio wrote:*   no. E' tutta questione di cluster. 
> 
> Siccome ho visto che usavate questo comando:
> 
> ```
> ...

 

basta pulirla  :Wink: 

----------

## Dr.Dran

 *emix wrote:*   

>  *federico wrote:*   Ma io ne ho 700 di mega... 
> 
> Be', ma voi contate pure i distfiles?

 

Beh non saprei, forse li ha compreso i distfiles, però tieni conto che il portage su filesystem con blocchi di 4K la dimensione media di portage va da 450 a 500 megabyte a seconda del filesystem utilizzato... boh, però sinceramente non saprei come mai ha un repositorio così grande  :Very Happy: 

----------

## emix

 *comio wrote:*   

> basta pulirla

 

 :Wink: 

A fini statistici il mio "tree" occupa 513MB, con reiserfs e con le impostazioni standard.

----------

## .:chrome:.

 *comio wrote:*   

> Io uso xfs che non è molto gentile con i file piccoli... 

 

falso

----------

## mambro

 *k.gothmog wrote:*   

>  *comio wrote:*   Io uso xfs che non è molto gentile con i file piccoli...  
> 
> falso

 

Il paladino di XFS colpisce ancora   :Twisted Evil:   :Laughing: 

Comunque vedo che nessuno l'ha proposto ma io sento molto la mancanza di pacchetti binari con cflags generiche (686, come fa archlinux.. difficilmente serve di meno) e magari tutte le useflag attive per non dare problemi (insomma seguire quello che fanno le altre distro per avere pacchetti binari) supportati ufficialmente... sarebbe bello che oltre ai soliti openoffice-bin, mplayer-bin, firefox-bin  ci sia un opzione di portage per installare qualsiasi cosa come binario.

----------

## comio

 *k.gothmog wrote:*   

>  *comio wrote:*   Io uso xfs che non è molto gentile con i file piccoli...  
> 
> falso

 

giusto, la frase che avrei dovuto dire era: la conf di default è con cluster da 4k che non sono l'ideal per file piccoli.

 :Smile: 

ciao

----------

## Onip

anche io trovo parecchio fastidiosi i "particolari" messi in luce in questi post. Probabilmente l'apertura di un bug report ci chiarirebbe le idee almeno su cosa ne pensano i devel

----------

## tizio

probabilmente sono io che non conosco un metodo migliore e quindi chiedo venia...

comunque trovo abbastanza fastidioso dover mascherare i pacchetti a mano dopo ogni sync... mi spiego...

se per quel che riguarda lo smascheramento il file /etc/portage/package.keywords funziona benissimo..

(benissimo finchÃ¨ quel pacchetto non Ã¨ mascherato in /usr/portage/profiles/package.mask... nel qual caso va tolto a mano o emerge non lo trova)

per far la cosa contraria invece (non voler aggiornare un determinato pacchetto) mi tocca di aggiornare con uno script il file /usr/portage/profiles/package.mask dopo ogni emerge --sync...

se invece esiste un metodo migliore per dirgli "fermati a questa versione" allora ditemelo please   :Very Happy: 

----------

## Kernel78

 *tizio wrote:*   

> probabilmente sono io che non conosco un metodo migliore e quindi chiedo venia...
> 
> comunque trovo abbastanza fastidioso dover mascherare i pacchetti a mano dopo ogni sync... mi spiego...
> 
> se per quel che riguarda lo smascheramento il file /etc/portage/package.keywords funziona benissimo..
> ...

 

Se vuoi mascherare tutte le versioni superiori ad quella installata di un certo pacchetto basta che metti nel package.mask 

```
>categoria/nome-versione
```

dove "versione" sarà la versione cha hai installata nel sistema.

/EDIT: io l'ho dato per scontato ma oltre al segno > puoi usare uno dei seguenti

```
>

<

=

>=

<=
```

----------

## Onip

 *tizio wrote:*   

> (benissimo finchÃ¨ quel pacchetto non Ã¨ mascherato in /usr/portage/profiles/package.mask... nel qual caso va tolto a mano o emerge non lo trova)

 

per questo c'è /etc/portage/package.unmask

----------

## .:chrome:.

@mambro:

non è per fare il paladino di XFS: era solo inesatto.

 *comio wrote:*   

> giusto, la frase che avrei dovuto dire era: la conf di default è con cluster da 4k che non sono l'ideal per file piccoli.

 

infatti questo è vero, ma è indipendente dal file system

----------

## Dr.Dran

 *k.gothmog wrote:*   

> infatti questo è vero, ma è indipendente dal file system

 

Vero, anche perchè reiser fa ...... anche con i file piccoli quando ha dei cluster da 4K se invece lo formatti con cluster da 512B bene va in segfault  :Very Happy: 

Comunque no vedo come mai tutta questa diffidenza su chi sostiene xfs, e' un valido filesystem e fra l'altro chi e' attento notera che dalla versione 2.6.16 del kernel le performance sono notevolmente migliorate, personalmente a parte nella partizione di boot (su cui installo un filesystem ext2) ho tutto il notebbok, il server e la workstation con xfs e cluster da 512B e non fa una crepa, tentete conto che il mio portatile e' un bel pò bistrattato fra spgnimenti improvvisi e altro, e non ho mai perso nulla di significativo, xfs perde solo i dati che ha momentaneamente in RAm, gli altri non li tocca.

 *mambro wrote:*   

> Comunque vedo che nessuno l'ha proposto ma io sento molto la mancanza di pacchetti binari con cflags generiche (686, come fa archlinux.. difficilmente serve di meno) e magari tutte le useflag attive per non dare problemi (insomma seguire quello che fanno le altre distro per avere pacchetti binari) supportati ufficialmente... sarebbe bello che oltre ai soliti openoffice-bin, mplayer-bin, firefox-bin  ci sia un opzione di portage per installare qualsiasi cosa come binario.

 

Beh per questo esistono apposta distribuzioni come archlinux e company, ma comuque nel wiki di gentoo sono elencati i pacchetto GRP per l'installazione binaria...... credimi che la tua esigenza e' una sensazione passeggera, fidati che una volta che provi Gentoo ed entri nella sua filosofia non la lasci +. (Per il resto... beh aguzzare l'ingegno e via... se no che siamo sistemisti e programmatori a fare se non troviamo soluzioni o sviluppiamo sistemi per risolvere i nostri problemi  :Very Happy: )

Cheers

Franco

----------

## Cazzantonio

Anche io vorrei tanto i pacchetti binari.   :Smile: 

Mi piace portage come packet-manager ma sinceramente non me ne frega assolutamente niente delle cflags e persino poco delle USE   :Rolling Eyes:  (sto iniziando a pensare che non valga la pena di perdere tutto questo tempo a compilare per avere la possibilità di selezionare le USE   :Smile:  )

Ok sono una cosa carina e magari anche molto utile in determinati ambienti (tipo server, dove ti serve un sistema minimale) ma decisamente sopravvalutata in ambiente desktop   :Rolling Eyes:  tanto va a finire che solo una minoranza di utenti utilizza configurazioni particolarmente esotiche di USE... la maggior parte si limiterà a selezionare quelle che gli garantiscono la maggiore compatibilità e la maggiore versatilità in tutti i campi che vengono in mente   :Rolling Eyes:  . Inoltre compilare causa troppo spesso problemi con librerie, errori, incompatibilità varie, etc... che sarebbero invece assenti nel caso di pacchetti già compilati e testati   :Rolling Eyes: 

Comunque sarei più che disposto a tollerare la storia della compilazione come male necessario se solo fossero risolti i problemi che ho postato all'inizio di questo thread   :Rolling Eyes: 

Che ne dite? Qualcuno vuole iniziare a stilare una lista dei problemi riscontrati? Almeno poi si fa un bel bug-report a nome di tutta la comunità italiana   :Smile: 

----------

## LastHope

Tornando IT su Portage...beh, fino a prima del 2.1 io era alquanto scocciato del tempo che ci metteva nell'aggiornare la cache ad ogni emerge --sync...ma quest'ultima versione (riprovato il sync oggi) secondo me ha migliorato notevolmente i tempi (non si rallenta più)...e per il resto, non so se è l'aggiornamento del gcc o del portage, ma anche l'aggiornamento di certi package è diventato molto puù veloce (prima della partita avevo fatto partire l'aggiornamento ad Xorg 6.8.7 e qualcosa...pensavo la solita oretta...e invece, velocissimo...  :Shocked:  )

Per il resto, concordo: anche io vorrei avere alla fine tutti i messaggi utili (tipo: devi lanciare python-updater, perl-cleaner, aggiornare questo database, occhio che questo file potrebbe adesso trovarsi qui...) oltre all'etc-update...sicuramente utile, più che scorrersi una sfilza infinita di righe alcune criptiche, alcune incapibili...

Per il resto, OT, ho una domanda: esiste un comando (un'opzione di emerge) per vedere se ci sono pacchetti che non sono più dipendenze di niente, e quindi eliminabili? Immagino faccia sempre parte del problema delle dipendenze inverse...

Ciao a tutti

LastHope

----------

## tizio

@Kernel78:

lo so che basta inserirlo in package.mask... il problema Ã¨ che devo farlo dopo ogni emerge --sync...

non Ã¨ un grosso problema basta farsi uno script ma sarebbe bello avere un modo per renderlo definitivo

@Onip:

dell'esistenza di package.unmask ero a conoscenza... ma anche se inserisco i pacchetti continuo a ricevere messaggi del tipo:

```

These are the packages that would be merged, in order:

Calculating world dependencies -

!!! Packages for the following atoms are either all

!!! masked or don't exist:

app-mobilephone/openobex-apps app-emulation/qemu

```

----------

## mambro

 *Dr.Dran wrote:*   

> 
> 
>  *mambro wrote:*   Comunque vedo che nessuno l'ha proposto ma io sento molto la mancanza di pacchetti binari con cflags generiche (686, come fa archlinux.. difficilmente serve di meno) e magari tutte le useflag attive per non dare problemi (insomma seguire quello che fanno le altre distro per avere pacchetti binari) supportati ufficialmente... sarebbe bello che oltre ai soliti openoffice-bin, mplayer-bin, firefox-bin  ci sia un opzione di portage per installare qualsiasi cosa come binario. 
> 
> Beh per questo esistono apposta distribuzioni come archlinux e company, ma comuque nel wiki di gentoo sono elencati i pacchetto GRP per l'installazione binaria...... credimi che la tua esigenza e' una sensazione passeggera, fidati che una volta che provi Gentoo ed entri nella sua filosofia non la lasci +. (Per il resto... beh aguzzare l'ingegno e via... se no che siamo sistemisti e programmatori a fare se non troviamo soluzioni o sviluppiamo sistemi per risolvere i nostri problemi )
> ...

 

Uso gentoo da 2 anni, quindi nn è una cosa passeggera. Resta il fatto che se ubuntu avesse la gestione degli script di avvio che ha gentoo e portage coi binari passerei a quella

----------

## codadilupo

 *tizio wrote:*   

> @Kernel78:
> 
> lo so che basta inserirlo in package.mask... il problema Ã¨ che devo farlo dopo ogni emerge --sync...
> 
> non Ã¨ un grosso problema basta farsi uno script ma sarebbe bello avere un modo per renderlo definitivo
> ...

 

si', ma qui il problema è che è mal scritto package.*!!

Coda

----------

## syntaxerrormmm

 *LastHope wrote:*   

> Per il resto, OT, ho una domanda: esiste un comando (un'opzione di emerge) per vedere se ci sono pacchetti che non sono più dipendenze di niente, e quindi eliminabili? Immagino faccia sempre parte del problema delle dipendenze inverse...

 Esisteva il pianto unclepine, ora si potrebbe usare (con una certa cautela) 

```
emerge --depclean -p
```

Sono d'accordo con Cazzantonio quando parla delle abitudini degli utenti desktop (o comunque non server, nonostante non abbia mai tirato su un server Gentoo) in tema di useflags, ma sono convinto che sia uno dei meccanismi che rende gentoo veramente flessibile nei confronti di altre distribuzioni.

Sono concorde anche io con il discorso del logger degli ewarn e con tutto il resto, complimenti, ottimo thread.

Ciao a tutti.

----------

## Dr.Dran

Ribadisco, per me sono problemi inutili le discussioni sui binari, se non volete perdere tempo compilando i pacchetti installate i pacchetti GRP e guardacaso sono GIA' COMPILATI; basta fare una ricerca nel wiki ed ecco QUI.

Inoltre ricordate questo:

la distribuzione Gentoo/Linux ha caratteristiche uniche nel suo genere, in primis essa non è una vera distribuzione pacchettizzata come (RedHat, Suse, Debian, etc. etc.) ma è considerata una metadistribuzione: Portage è il sistema di gestione dei pacchetti Gentoo, esso è una applicazione scritta in python e prende spunto dal sistema di porting dei pacchetti di BSD, è basato sul download dei pacchetti sorgenti e la compilazione dei medesimi rispettandone le dipendenze, sebbene sia anche compreso il supporto per precompilati.

Tramite le flag USE, una delle feature caratteristiche di Portage, l'utente può attivare o disattivare opzioni fornite con i pacchetti che possono essere utili o inutili a seconda del tipo di installazione che vogliamo andare a fare, per questo non esiste una vera e propria versione di Gentoo per  sistemi Server o Desktop o Embedded, insomma Gentoo è Gentoo e basta!!!

In secondo piano, ma non da trascurare, ricordatevi che gento e' l'unica distribuzione che rilascia una versione STABLE con i software + aggiornati rispetto alle altre versioni di produzione delle altre distro.... provare per credere.

In terzo piano, provate ad installare un pacchetto con gentoo, bene se voglio XORG beh mi scarica 4 o 5 pacchetti di cui il programma principale l'xterm e altri due o tre pacchetti... beh provate cone Debian... mi sembra che l'ultima volta installasse ben 10/15 pacchetti... ah se su un server volete installare cups, beh in gento scaricate i sorgenti di cups e basta in debian vi butta su xorg-common e altre merdate... che non ve ne fate nulla... beh tutto qui e ditemi se non e' comodità e poi emerge si occupa delle dipendenze e inoltre se utilizzate una versione stable con CFLAGS safe... insomma a me e' sempre andato tutto e non mi si e' incasinato niente...

Cheers

Franco

----------

## Cazzantonio

 *Dr.Dran wrote:*   

> la distribuzione Gentoo/Linux ha caratteristiche uniche nel suo genere,

 

Infatti era stato premesso all'inizio del thread che portage ci piace   :Smile:  (sennò non useremmo gentoo)

Nonostante il giudizio complessivo sia positivo secondo me (e altri) ci sono dei difetti che potrebbero essere corretti   :Rolling Eyes: 

Per esempio l'iniziativa di paludis (che vorrebbe essere un clone di portage da quanto ho capito) è carina... ovvero implementare in portage tutta una serie di features che per ora mancano   :Rolling Eyes: 

 *Quote:*   

> In secondo piano, ma non da trascurare, ricordatevi che gento e' l'unica distribuzione che rilascia una versione STABLE con i software + aggiornati rispetto alle altre versioni di produzione delle altre distro.... provare per credere.

 

Tra sostenere di essere stabili ed esserlo c'è una bella differenza   :Rolling Eyes: 

Secondo me gentoo è stabile ma molti utenti più esigenti potrebbero ritenere che gli occasionali problemi di compilazione sperimentati da ogni utente gentoo siano da considerarsi instabilità   :Rolling Eyes: 

 *Quote:*   

> In terzo piano, provate ad installare un pacchetto con gentoo, bene se voglio XORG beh mi scarica 4 o 5 pacchetti di cui il programma principale l'xterm e altri due o tre pacchetti... beh provate cone Debian... mi sembra che l'ultima volta installasse ben 10/15 pacchetti... 

  che portage funzioni meglio di apt mi pare quasi lapalissiano... IMHO ovviamente   :Smile:   :Wink: 

 *Quote:*   

> a me e' sempre andato tutto e non mi si e' incasinato niente...

 

Beato te   :Smile: 

A me si è incasinata diverse volte... tipo non riesco a compilare con successo scilab >2.7 per motivi vari, evince non mi apre i pdf e non capisco perché, mi da problemi con librerie unlinked... e questi sono solo i problemi che ho ora  :Smile:   :Wink: 

----------

## !equilibrium

 *Cazzantonio wrote:*   

> (sto iniziando a pensare che non valga la pena di perdere tutto questo tempo a compilare per avere la possibilità di selezionare le USE   )
> 
> Ok sono una cosa carina e magari anche molto utile in determinati ambienti (tipo server, dove ti serve un sistema minimale) ma decisamente sopravvalutata in ambiente desktop   tanto va a finire che solo una minoranza di utenti utilizza configurazioni particolarmente esotiche di USE... la maggior parte si limiterà a selezionare quelle che gli garantiscono la maggiore compatibilità e la maggiore versatilità in tutti i campi che vengono in mente   . Inoltre compilare causa troppo spesso problemi con librerie, errori, incompatibilità varie, etc... che sarebbero invece assenti nel caso di pacchetti già compilati e testati   

 

le USE sono valide anche in ambito desktop, non solo server, e hanno un enorme vantaggio rispetto ai precompilati, ovvero se compili i vari pacchetti con le estensioni che effettivamente ti servono, hai molte meno probabilità di incappare nei tipici bugs generati dall'incompatibilità delle diverse estensioni. Problemi tipici invece di un sistema interamente precompilato, dove tutti i i pacchetti sono compilati con il supporto a TUTTO e non sempre TESTATI a dovere; senza contare l'appesantimento inutile dei binari, e l'installazione di librerie non richieste. Infine aggiungo, gli ebuilds di portage evitano sul nascere che un tal pacchetto venga compilato con il supporto ad estensioni non compatibili tra di loro, avvertendo l'utente e invitandolo a cambiare le USE, lo stesso non si può dire per i pre-compilati delle altre distro dove un upgrade di un semplice componente può essere fatale per tutta la distro (l'ultimo esempio che mi viene in mente a riguardo è il pacchetto udev di debian rilascio ad aprile, il quale se installato non permetteva più di fare il boot della macchina... in gentoo questi casi sono molto rari).

 *Cazzantonio wrote:*   

>  ovvero se avete installato un pacchetto slotted dovete ricordarvelo voi... non esiste alcun tool ufficiale in grado di rimuovere le versioni vecchie!  Immaginate solo quanto sia pratico avere 15 versioni diverse e inutili di gentoo-sources o di kdelibs.... ok direte voi... sei un utente navigato, lo sai e li rmuovi a mano... 

 

falso:

```
equery l --duplicates -i
```

un man equery ci sta tutto.

----------

## federico

Scusate la mia ingenuita' ma una domanda nasce spontanea.

Per quale motivo il mio file system reiserfs3 ha come dimensione di default cluster da 4kb al posto di 512b se questi ultimi ottimizzano il disco? Qual'e' l'altra faccia della medaglia?

Per quello che riguarda l'albero di portage nell'ultimo post che ho fatto ho sbagliato, ho una dimensione di circa 500 mega, anche se per qualcuno "coi dischi di oggi cosa vuoi che siano 500 mega", io con quello spazio ci farei qualcos'altro se lo avessi a disposizione...  :Smile: 

```

altair ~ # cd /usr/portage/distfiles/

altair distfiles # rm -rf *

altair distfiles # cd ..

altair portage # du -shc *

1.2M    app-accessibility

5.7M    app-admin

292K    app-antivirus

2.8M    app-arch

1.2M    app-backup

557K    app-benchmarks

2.0M    app-cdr

2.2M    app-crypt

4.4M    app-dicts

2.7M    app-doc

3.0M    app-editors

5.1M    app-emacs

3.2M    app-emulation

681K    app-forensics

3.2M    app-i18n

954K    app-laptop

6.4M    app-misc

965K    app-mobilephone

2.6M    app-office

1.6M    app-pda

1.2M    app-portage

1.5M    app-shells

8.7M    app-text

2.2M    app-vim

2.3M    app-xemacs

517K    dev-ada

1.5M    dev-cpp

4.1M    dev-db

1.6M    dev-dotnet

1.4M    dev-embedded

1.1M    dev-games

913K    dev-haskell

9.5M    dev-java

5.4M    dev-lang

11M     dev-libs

6.3M    dev-lisp

757K    dev-ml

19M     dev-perl

2.3M    dev-php

613K    dev-php4

1.6M    dev-php5

8.8M    dev-python

4.5M    dev-ruby

533K    dev-scheme

1.3M    dev-tcltk

1.8M    dev-tex

292K    dev-tinyos

9.0M    dev-util

0       distfiles

1.8M    eclass

1.7M    games-action

2.6M    games-arcade

1.5M    games-board

2.7M    games-emulation

328K    games-engines

3.1M    games-fps

360K    games-kids

1.4M    games-misc

537K    games-mud

1.9M    games-puzzle

621K    games-roguelike

741K    games-rpg

421K    games-server

453K    games-simulation

404K    games-sports

1.6M    games-strategy

733K    games-util

2.8M    gnome-base

2.4M    gnome-extra

737K    gnustep-apps

348K    gnustep-base

457K    gnustep-libs

4.0K    header.txt

15M     kde-base

1.4M    kde-misc

6.3M    licenses

2.4M    mail-client

2.0M    mail-filter

2.5M    mail-mta

2.4M    media-fonts

5.6M    media-gfx

11M     media-libs

9.8M    media-plugins

440K    media-radio

12M     media-sound

1.3M    media-tv

7.0M    media-video

98M     metadata

8.2M    net-analyzer

3.2M    net-dialup

1.6M    net-dns

1.1M    net-firewall

1.3M    net-fs

1.5M    net-ftp

3.9M    net-im

2.4M    net-irc

3.3M    net-libs

4.5M    net-mail

14M     net-misc

983K    net-nds

476K    net-news

657K    net-nntp

3.1M    net-p2p

1.4M    net-print

1.2M    net-proxy

3.1M    net-wireless

2.2M    net-www

2.8M    net-zope

1.1M    perl-core

4.1M    profiles

392K    rox-base

473K    rox-extra

312K    sci-astronomy

1.5M    sci-biology

754K    sci-calculators

1.7M    sci-chemistry

1.1M    sci-electronics

252K    sci-geosciences

2.3M    sci-libs

1.3M    sci-mathematics

553K    sci-misc

553K    sci-visualization

40K     scripts

1.3M    sec-policy

4.0K    skel.ChangeLog

8.0K    skel.ebuild

4.0K    skel.metadata.xml

11M     sys-apps

991K    sys-auth

1.1M    sys-block

1.3M    sys-boot

2.3M    sys-cluster

3.8M    sys-devel

931K    sys-freebsd

3.6M    sys-fs

2.4M    sys-kernel

3.6M    sys-libs

966K    sys-power

1.4M    sys-process

1.2M    virtual

1.1M    www-apache

3.5M    www-apps

2.1M    www-client

473K    www-misc

1.7M    www-servers

2.2M    x11-apps

793K    x11-base

2.6M    x11-drivers

4.7M    x11-libs

7.0M    x11-misc

6.0M    x11-plugins

637K    x11-proto

1.1M    x11-terms

3.1M    x11-themes

2.5M    x11-wm

817K    xfce-base

1.6M    xfce-extra

513M    total

```

----------

## !equilibrium

 *federico wrote:*   

> "coi dischi di oggi cosa vuoi che siano 500 mega", io con quello spazio ci farei qualcos'altro se lo avessi a disposizione... 

 

il mio discorso era da intendersi in un altro contesto, nel senso: non sono i 400MB guadagnati con la compressione dei 500MB di portage in 100MB, che ti cambiano la vita. se davvero vuoi recuperare spazio, ti basta formattare i clusters a 512bit e recuperi ben oltre i 400MB di cui si parlava  :Wink:  si parla di GB!! (a seconda della capienza dei dischi ovviamente)

(IMHO) è inutile tentare di ottimizzare una piccola parte del filesystem, quando esiste una soluzione sicuramente migliore e più elegnate che si può applicare a tutto il tree di dati ed è indipendente da qualsiasi filesystem. si evita anche di installare software aggiuntivo e/o che rallenta il proprio sistema (ipotizzando di comprire tutto portage, c'è da considerare l'aggiunga del tempo necessario per la decompressione dei dati ogni volta che viene lanciato emerge). Questo intendevo, cioè che valutando i pro e contro delle varie soluzioni, l'uso dei clusters a 512bit è sicuramente quello più efficiente e senza controindicazioni.

----------

## Cazzantonio

 *!equilibrium wrote:*   

> 
> 
> ```
> equery l --duplicates -i
> ```
> ...

 

Bravo ok... il fatto è che serve a poco   :Smile: 

Anche  

```
equery list |grep "/"  | sed -e 's/-[0-9]/*/g' | cut -d"*" -f1 |sort|uniq -d
```

  fa la stessa cosa... questo è scritto addirittura in man bash  :Rolling Eyes:   :Smile: 

Anche 

```
emerge -pe world |grep ebuild|cut -d"]" -f2|cut -d" " -f2 | sed -e 's/-[0-9]/*/g' | cut -d"*" -f1 |sort|uniq -d
```

  :Smile:  (qua non ti leggi nemmeno il man di equery   :Wink:  )

Mi serve a poco sapere quali sono i pacchetti duplicati se poi non riesco a stabilire se sono dipendenza di qualcosa o no (e quindi li posso cancellare senza pietà   :Smile:  )

Anche nello script postato precedentemente usavo questa feature di equery... peccato che poy equery depends non faccia il suo lavoro    :Rolling Eyes: 

Comunque sono tutti workaround... anche emerge --depclean porebbe dirti quali sono i pacchetti slotted e le versioni di tali pacchetti eventualmente da rimuovere... tuttavia non lo fa   :Rolling Eyes: 

Unclepine lo faceva e sinceramente mi piacerebbe tanto che questo fosse il comportamento di default di portage e di non dover ricorrere a tool esterni   :Smile: 

In sostanza rimane vero quanto ho detto prima: "non esiste alcun tool ufficiale in grado di rimuovere le versioni vecchie" e man equery non risponde a questa domanda   :Wink: 

----------

## !equilibrium

 *Cazzantonio wrote:*   

> ovvero se avete installato un pacchetto slotted dovete ricordarvelo voi.

 

equery l --duplicates -i ti da la lista degli slotted, sei tu che hai messo in dubbio il fatto che non ci sia uno strumento 'ufficiale' in grado di monitorarli.

 *Cazzantonio wrote:*   

> Mi serve a poco sapere quali sono i pacchetti duplicati se poi non riesco a stabilire se sono dipendenza di qualcosa o no (e quindi li posso cancellare senza pietà   )

 

questo dubbio sulle dipendenze degli slotted te lo concedo, ma non posso che quotare e ripetere il discorso fatto da k.gothmog in precedenza, ovvero, sei sicuro che equery riporti gli errori da te riscontrati? a me per esempio non li da, sia che faccio query passando l'atom completo di versione che non, i risultati sono sempre corretti e coerenti. Ciò non toglie che tu possa aver trovato un bug e quindi ci sia da fare un bugreport.

 *Cazzantonio wrote:*   

> In sostanza rimane vero quanto ho detto prima: "non esiste alcun tool ufficiale in grado di rimuovere le versioni vecchie" e man equery non risponde a questa domanda 

 

la mia precedente 'ripresa' non era su questa affermazione, ma sulla questione degli slotted, c'è stato un 'quoting' di tue frasi che non dovevano essere quotate, mio errore, chiedo scusa per l'incomprensione.

----------

## Cazzantonio

 *!equilibrium wrote:*   

> equery l --duplicates -i ti da la lista degli slotted, sei tu che hai messo in dubbio il fatto che non ci sia uno strumento 'ufficiale' in grado di monitorarli.

 

No di rimuoverli se non servono....  o forse mi sono espresso male io

 *!equilibrium wrote:*   

> questo dubbio sulle dipendenze degli slotted te lo concedo, ma non posso che quotare e ripetere il discorso fatto da k.gothmog in precedenza, ovvero, sei sicuro che equery riporti gli errori da te riscontrati? a me per esempio non li da, sia che faccio query passando l'atom completo di versione che non, i risultati sono sempre corretti e coerenti. Ciò non toglie che tu possa aver trovato un bug e quindi ci sia da fare un bugreport.

 

Hai provato a usare il mio script?   :Smile:   Tenta equery depends su tutti i pacchetti installati... guarda e giudica te il risultato   :Smile: 

----------

## federico

 *!equilibrium wrote:*   

> l'uso dei clusters a 512bit è sicuramente quello più efficiente e senza controindicazioni.

 

Ho capito che devo formattare il pc, ma mi sparo :/ Che pacco, ma perche' nn e' l'opzione di default se e' cosi' buona?  :Sad:  Tristissimo...

----------

## bandreabis

Idem con patate. 

Ma preferirei fare backup prima di riformattare.

Ca@#o si ride il mio avatar!

----------

## Raffo

@Federico: sono in prossimità di formatto, almeno per me questo topic casca bene  :Very Happy: 

----------

## Cazzantonio

questi tanto per rendere chiaro quanto equery depends non funzioni :

https://bugs.gentoo.org/show_bug.cgi?id=119876

https://bugs.gentoo.org/show_bug.cgi?id=124053

https://bugs.gentoo.org/show_bug.cgi?id=124552

https://bugs.gentoo.org/show_bug.cgi?id=126739

https://bugs.gentoo.org/show_bug.cgi?id=130345

https://bugs.gentoo.org/show_bug.cgi?id=137776

----------

## X-Drum

 *mambro wrote:*   

> Uso gentoo da 2 anni, quindi nn è una cosa passeggera.

 

invece lo è, ma lo sviluppo di gentoo non incentrato al 90% o solamente su portage,

domanda: quanti progressi hai visto fare a portage in questi 2 anni?

 *mambro wrote:*   

> Resta il fatto che se ubuntu avesse la gestione degli script di avvio che ha gentoo e portage coi binari passerei a quella

 

 :Rolling Eyes: 

edit:

 *Dr.Dran wrote:*   

> Ribadisco, per me sono problemi inutili le discussioni sui binari, se non volete perdere tempo compilando i pacchetti installate i pacchetti GRP e guardacaso sono GIA' COMPILATI

 

che innovazione  :Very Happy: 

ah ecco cosa voleva dire quel binary asdalol

sottoscrivo quanto detto da Dr.Dran, questo topic sta divenendo l'ennesimo inutile topic su pacchetti binari,ecc

-non vi piace gentoo o il suo motus operandi?

-state sprecando il vostro prezioso tempo dietro ad un compilatore?

..non usatela e fine della storia, ma sopratutto ,e rivolto a tutti, basta con questi 3d

----------

## Dr.Dran

@X-Drum

Grazie mille hai centrato per bene il mio messaggio  :Very Happy: 

Cheers

Franco

----------

## federico

 *X-Drum wrote:*   

> 
> 
> -non vi piace gentoo o il suo motus operandi?
> 
> -state sprecando il vostro prezioso tempo dietro ad un compilatore?
> ...

 

Permettetemi ma a me questo thread pare interessante, tanto piu' che se qualche sviluppatore della comunita' sta leggendo potrebbe farsi venire in mente idee per ottimizzare alcuni sistemi di gestione che non sono perfomanti sotto gentoo e rendere cosi' la distribuzione migliore.

Se c'e' qualcosa che pare valido ma non perfetto, lo stile opensource ci insegna che possiamo discuterne con altri utenti e organizzarci per migliorare le cose.

Federico

----------

## X-Drum

 *federico wrote:*   

> 
> 
> Se c'e' qualcosa che pare valido ma non perfetto, lo stile opensource ci insegna che possiamo discuterne con altri utenti e organizzarci per migliorare le cose.

 

si quest'ultima frase e' corretta, ma federico qui si parte con i "problemi di portage"

,nulla da ridire su questo discussione costruttiva per carita', per poi arrivare 

a parare ed a parlare del solito argomento "binari vs sorgenti" (rileggi il 3d se non ci credi)

e questo mi pare eccessivo oltre ad essere terribilmente OT ed inconcludente

----------

## federico

 *X-Drum wrote:*   

> si quest'ultima frase e' corretta, ma federico qui si parte con i "problemi di portage"
> 
> ,nulla da ridire su questo discussione costruttiva per carita', per poi arrivare 
> 
> a parare ed a parlare del solito argomento "binari vs sorgenti" (rileggi il 3d se non ci credi)
> ...

 

Ho letto tutto il thread man mano che cresceva, anche io casserei la discussioni su "si ma mi scoccia che devo compilare tutto" perche' quello e' strutturale, se cambi quello cambi distro e punto ^^ (Quindi, per farla breve, sono daccordo con te) ma ho provato un sottile piacere nel leggere che anche secondo altri portage andrebbe modernizzato in maniera radicale.

----------

## mambro

 *X-Drum wrote:*   

> 
> 
>  *Dr.Dran wrote:*   Ribadisco, per me sono problemi inutili le discussioni sui binari, se non volete perdere tempo compilando i pacchetti installate i pacchetti GRP e guardacaso sono GIA' COMPILATI 
> 
> che innovazione 
> ...

 

Sapete bene che c'è differenza tra fare una installazione coi pacchetti grp e una distro basata sui binari.. non è la stessa cosa. Comunque probabilmente avete ragione nel dire che gentoo con pacchetti binari non sarebbe più gentoo. Ma io non chiedo SOLO binari, chiedo ANCHE binari..  Se venisse mantenuto un repository coi binari per installare tutto il software di portage con emerge -k non penso sarebbe così tragico..

----------

## xlyz

http://distrowatch.com/weekly.php?issue=20060626#news

----------

## Cazzantonio

 *X-Drum wrote:*   

> 
> 
> -non vi piace gentoo o il suo motus operandi?
> 
> -state sprecando il vostro prezioso tempo dietro ad un compilatore?
> ...

 

Bah... penso che discutere di eventuali problemi di portage da risolvere sia una cosa costruttiva...

Che equery depends abbia dei problemi è ovvio no? Dovremmo semplicemente dire "pazienza"?  :Rolling Eyes: 

Che portage potrebbe integrare tante feature che per ora non ha anche questo è lapalissiano... dovrei stare zitto in nome del fatto che i developer di portage sono divinità incontestabili?  :Wink: 

Il fatto che questo thread stia degenerando a parlare di binari vs sorgenti mi dispiace... trovo che sia leggermente OT ma non così OT da meritare una correzione... io volevo parlare di altro ma se l'unico problema che emerge secondo la maggior parte degli utenti è il fatto che gentoo non abbia i binari (o non abbia un supporto per i binari paragonabile a quello per i sorgenti... così mi sembra più esatto) lo accetto e ne prendo atto.  :Rolling Eyes: 

Se pensi che questi thread siano una perdita di tempo sei liberissimo di non leggerli in pieno stile gentoo "all is about choiche"   :Smile:   :Wink: 

P.S. spererei anche io che da questa discussione emergesse qualcosa di più della solita trita discussione "binari vs sorgenti"   :Rolling Eyes:   :Smile: 

----------

## emix

 *Cazzantonio wrote:*   

> P.S. spererei anche io che da questa discussione emergesse qualcosa di più della solita trita discussione "binari vs sorgenti"   

 

Idem... tra l'altro ci sono un sacco di distribuzioni binarie valide da poter usare, e Gentoo ci piace così com'è perché è alternativa e quasi unica nel suo genere.

Ritornando a portage, a quelli che lo criticano consiglierei di provare freebsd  :Rolling Eyes:  non avete idea di come lo rimpiangereste  :Laughing: 

Ma questo non è un buon motivo per non volerlo migliorare e da questo punto di vista ben vengano progetti come paludis che tentano di esplorare delle alternative per dare (magari) degli spunti agli sviluppatori di portage.

----------

## X-Drum

 *Cazzantonio wrote:*   

> 
> 
> Bah... penso che discutere di eventuali problemi di portage da risolvere sia una cosa costruttiva...

 

Cazzantonio è quello che penso anche io, il problema pero' è che bisognerebbe parlare di quello,

evitando le solite uscite del tipo: "ricompilare tutto è una perdita di tempo blabla"

 *Cazzantonio wrote:*   

> 
> 
> Che equery depends abbia dei problemi è ovvio no? Dovremmo semplicemente dire "pazienza"? 

 

si è ovvio e risaputo da parecchio tempo, e discuterne è perfettamente legittimo, e su questo

mi pare che concordino tutti (me compreso)

 *Cazzantonio wrote:*   

> 
> 
> Che portage potrebbe integrare tante feature che per ora non ha anche questo è lapalissiano... dovrei stare zitto in nome del fatto che i developer di portage sono divinità incontestabili?  

 

nessuno ti vuole zittire, per carita', non credere di avere a che fare con gente che difende a spada tratta anche

soluzioni fallimentari, per l'ennesima volta dato che non è chiaro a quanto vedo, le discussioni su portage

sono perfettamente legittime e una "seria autocritica" non puo' che essere costruttiva, ma se permetti

a me ed altre persone girano le scatole e non poco quando un 3d come questo che tratta argomenti 

interessanti ed importanti degenera in quello che è stato segnalato,

I developer? gente che si fa un mazzo cosi e spesso solo per la gloria o la voglia di farlo, divinizzarli

no, rispettarli, comprendere la difficoltà e l'impegno profuso nel progetto magari si, frasi del tipo:

"in N tempo non è stato ancora fatto nulla per correggere XXX"

mi chiedo che significato possa avere una frase del genere :X

 *Cazzantonio wrote:*   

> 
> 
> Il fatto che questo thread stia degenerando a parlare di binari vs sorgenti mi dispiace... trovo che sia leggermente OT ma non così OT da meritare una correzione... io volevo parlare di altro ma se l'unico problema che emerge secondo la maggior parte degli utenti è il fatto che gentoo non abbia i binari (o non abbia un supporto per i binari paragonabile a quello per i sorgenti... così mi sembra più esatto) lo accetto e ne prendo atto. 
> 
> Se pensi che questi thread siano una perdita di tempo sei liberissimo di non leggerli in pieno stile gentoo "all is about choiche"   
> ...

 

no penso che certi atteggiamenti vadano arginati o ripresi, ma questo non rientra nelle mie mansioni, quindi mi limito come altri

ad esprimere la mia opinione, nella speranza che la gente capisca   :Rolling Eyes: 

 *Cazzantonio wrote:*   

> 
> 
> P.S. spererei anche io che da questa discussione emergesse qualcosa di più della solita trita discussione "binari vs sorgenti"   

 

è quello che si augurano tutti credo

----------

## Scen

 *Cazzantonio wrote:*   

> 1)Possibile che ancora nessuno abbia sviluppato un modo intelligente per far stampare tutte le einfo, ewarn e quant'altro  di importante dica emerge alla fine di una compilazione alla fine di ogni catena di compilazioni??  
> 
> Che diavolo serve che emerge mi stampi degli avvertimenti se sto aggiornando contemporaneamente diversi pacchetti e ogni scritta permane sullo schermo solo pochi secondi (se va bene)?? Questa mi sembra davvero una presa per il culo...  
> 
> Non è nemmeno tanto difficile da implementare... basta buttare tutte le informazioni ALLA FINE e non DURANTE il processo di emersione...  
> ...

 

Hai già provato Enotice? Io lo uso e mi trovo benissimo, l'unica rottura è che se non lo si controlla periodicamente (e si effettuano aggiornamenti ricorrenti) ci si ritrova con qualche centinaio di logs da leggere  :Razz: 

----------

## !equilibrium

 *xlyz wrote:*   

> http://distrowatch.com/weekly.php?issue=20060626#news

 

@xlyz non capisco il senso di questo post   :Confused: 

se il tuo intento era quello di far porre attenzione sul fatto che Gentoo è in crisi, bhe stai facendo disinformazione, e la smentita viene proprio dai devels di gentoo: http://blog.stuartherbert.com/gentoo.php/2006/06/27/gentoo_isn_t_going_anywhere_but_forwards

p.s.: l'articolo di distrowatch del link citato è stato fatto senza nemmeno interpellare i devels di gentoo, e da gente che non ha mai usanto gentoo in vita loro... quindi sono solo parole al vento   :Laughing: 

----------

## mambro

Ok visto che binari vs sorgenti non è molto gettonata (lo so che se ne è parlato in passato ma magari insistendo qualcosa si ottiene..) aggiungerò qualche altra features che mi farebbe comodo:

- Rimozione che tenga conto delle dipendenze (emerge -C leva solo il pacchetto selezionato)

- un sistema che permetta, una volta selezionato un pacchetto masked, di smascherare le dipendenze necessarie (quello che una volta si faceva con "ACCEPT_KEYWORDS="~x86" emerge qualcosa").. so che ci sono già script che lo fanno ma sarebbe comodo qualcosa di integrato che magari controlli se i pacchetti necessari non sono più masked e li elimini da package.keywords)

- Un qualcosa di alternativo a emerge --sync.. è troppo lento, andrebbe trovato un altro sistema. Magari, come qualcuno ha già detto, lasciare gli ebuild in remoto non sarebbe male. Non aumentarebbe il traffico per il semplice fatto che ognuno scaricherebbe solo gli ebuild necessari e non TUTTI come accade adesso. Non è bello che apt-get update ci metta secondi e emerge --sync minuti e minuti.

----------

## X-Drum

 *mambro wrote:*   

> Ok visto che binari vs sorgenti non è molto gettonata (lo so che se ne è parlato in passato ma magari insistendo qualcosa si ottiene..) 
> 
> 

 

piu che non essere molto gettonata il discorso sarebbe un'altro ma a quanto pare ancora non è chiaro

il concetto, nostante sia stato ribadito piu' volte 

 *mambro wrote:*   

> 
> 
> - Rimozione che tenga conto delle dipendenze (emerge -C leva solo il pacchetto selezionato)
> 
> 

 

la mancanza di tale feature è critica e conosciuta, essendo importantissima per mantenere il sistema pulito e coerente,

è forse uno dei problemi piu' significativi che affligge allo stato attuale portage e quindi gentoo.

al momento tutto cio che si puo fare per arginare il problema è appunto:

-una corretta scelta delle USE (wide system, per package)

-l'emersione di pacchetti con le opzioni --deep --newuse

-l'uso congiunto (quando necessario) di emerge --depclean e di revdep-rebuild

-la correttezza del word file

Effettivamente per portage sarebbe un notevole passo in avanti il non doversi appoggiare

a "operazioni esterne" oltre alle normali operazioni di emersione/disinstallazione, per

il mantenimento di un sistema coerente.

 *mambro wrote:*   

> 
> 
> - un sistema che permetta, una volta selezionato un pacchetto masked, di smascherare le dipendenze necessarie (quello che una volta si faceva con "ACCEPT_KEYWORDS="~x86" emerge qualcosa").. so che ci sono già script che lo fanno ma sarebbe comodo qualcosa di integrato che magari controlli se i pacchetti necessari non sono più masked e li elimini da package.keywords)
> 
> 

 

una gestione diretta di tali files piu' l'eventuale purge dalle entry non piu' necessarie

(vedi keywords su determinata versione) semplificherebbe la vita notevolemente a tutti

e velocizzerebbe il tutto, concordo appieno

 *mambro wrote:*   

> 
> 
> - Un qualcosa di alternativo a emerge --sync.. è troppo lento, andrebbe trovato un altro sistema. Magari, come qualcuno ha già detto, lasciare gli ebuild in remoto non sarebbe male. Non aumentarebbe il traffico per il semplice fatto che ognuno scaricherebbe solo gli ebuild necessari e non TUTTI come accade adesso. Non è bello che apt-get update ci metta secondi e emerge --sync minuti e minuti.

 

il problema del sync imho è proprio portage, ovviamente piu' applicazioni supporti e pacchettizzi (come distro)

piu' vedrai il tuo repository divenire enorme, spesso mi sono interrogato sull'attuale situazione, e sulla possibilità

si sostituire gli ebuild con qualcos'altro o di far fetchare a portage solo una parte delle informazioni (metadata+lista ebuilds?)

insomma il necessario per il calcolo delle dipendenze, permettendogli di fetchare il vero e proprio ebuild in un secondo tempo,

ovvero poco prima dell'emersione.

Il risultato sarebbe un portage magari piu' snello (ammesso che nella pratica una cosa simile sia realizzabile senza troppo dispendio di banda

e senza mutare le attuali funzionalità) ma potenzialmente inutilizzabile se privo di ebuild in cache, e quindi connessione internet.

Preciso che queste sono solo congetture,idee pazzoidi e possibilmente irrealizabili.

----------

## federico

 *X-Drum wrote:*   

> e senza mutare le attuali funzionalità) ma potenzialmente inutilizzabile se privo di ebuild in cache, e quindi connessione internet.

 

Io andrei per questa strada se potessi mettere un gettone, perche' anche al momento attuale senza connessione a internet il sistema di portage non e' utilizzabile.

----------

## ercoppa

Anche io sono d'accordo che:

-andrebbe risolto il problema delle dipendenze inverse

-dovrebbe essere in auto lo smascheramento dei pacchetti (magari facendo uno screen di tutti quelli necessari e ponendo una domanda y/n)

Invece io non cambierei il sistema di sync di portage, o meglio se possibile velocizzarlo, ma senza stravoregerlo, trovo molto comodo gli ebuild in locale, e fracamente non rimpiango per nulla la velocità di apt-get (di aspettare 40/50 sec non mi pesa)

Chairamente IMAO

----------

## Cazzantonio

 *X-Drum wrote:*   

>  *mambro wrote:*   Ok visto che binari vs sorgenti non è molto gettonata (lo so che se ne è parlato in passato ma magari insistendo qualcosa si ottiene..) 
> 
>  
> 
> piu che non essere molto gettonata il discorso sarebbe un'altro ma a quanto pare ancora non è chiaro
> ...

 

Intendiamoci... io sono dell'idea che tutte i pacchetti esosi in compilazione che non hanno use particolari potrebbero essere presenti anche in versione binaria   :Smile: 

per esempio ho passato ore a compilare la libreria sci-libs/blas-atlas che ha solo questa use: USE="-doc"   :Rolling Eyes: 

una versione -bin come per openoffice sarebbe benvenuta ma non mi sembra uno stravolgimento di portage...

semmai un invito a fornire per più pacchetti la versione "-bin" rispetto a quanto si faccia ora   :Smile: 

per il resto quoto tutto   :Smile: 

Secondo me i problemi principali sono:

A) la corretta gestione delle dipendenze (inverse) che è poi il punto di partenza per tool come emerge --depclean e soci (in pratica se equery depends funzionasse basterebbe uno script bash per fare quello che faceva unclepine)

B) la gestione degli upgrade massicci con delle funzionalità per fornire informazioni nel modo più user-friendly possibile (elog e aggiornamenti critici)

C) una più trasparente gestione dei virtual... ovvero mi piacerebbe vedere con più facilità le varie versioni dei pacchetti che soddisfano un determinato virtual   :Smile: 

Gli alti problemi (a parte quello del sync che trovo complesso da risolvere e comunque è solo una questione di tempo... non di funzionalità... se avete fretta gentoo non fa per voi   :Wink:   :Smile:  ) mi sembrano minori o comunque risolvibili con semplici workaround   :Rolling Eyes:  ... comunque sempre feature interessanti rimangono   :Smile: 

----------

## bandreabis

 *!equilibrium wrote:*   

> se davvero vuoi recuperare spazio, ti basta formattare i clusters a 512bit e recuperi ben oltre i 400MB di cui si parlava  si parla di GB!! (a seconda della capienza dei dischi ovviamente)
> 
> l'uso dei clusters a 512bit è sicuramente quello più efficiente e senza controindicazioni.

 

Non sono sotto gentoo, ma vorrei documentarmi su come formattare i cluster a 512bit.... non ho trovato un manuale di mkreiserfs su internet che dia come possibile tale formattazione... è possibile con questo filesystem (versione 3) o ho solo trovato man vecchi?

Andrea

----------

## Cazzantonio

@bandreabis

Sei OT....

----------

## Onip

 *Cazzantonio wrote:*   

> 
> 
> A) la corretta gestione delle dipendenze (inverse) che è poi il punto di partenza per tool come emerge --depclean e soci (in pratica se equery depends funzionasse basterebbe uno script bash per fare quello che faceva unclepine)
> 
> B) la gestione degli upgrade massicci con delle funzionalità per fornire informazioni nel modo più user-friendly possibile (elog e aggiornamenti critici)
> ...

 

Quoto in toto, ma porrei un attimo l'accent sulla rimozione delle dipendenze inverse. Io non le toglierei al tempo dell'emerge -C, ma lascerei un sistema simile al --depclean attuale (funzionante a pieno, ovvio). Così facendo mi eviterei ricompilazioni (inutili e lunghe) di dipendenze comuni a più applicazioni. Mi spiego meglio: sia A sia B richiedono C (ed es, invento, grip e ripperx che richiedono lame). Se io voglio passare dall'uno all'altro posso togliere A e mettere B, in questo caso ricompilerei inutilmente C. 

A quando il bug-report comune?

Byez

p.s. spero di essere stato abbastanza chiaro, con 'sto caldo...

----------

## emix

 *Onip wrote:*   

> Mi spiego meglio: sia A sia B richiedono C (ed es, invento, grip e ripperx che richiedono lame). Se io voglio passare dall'uno all'altro posso togliere A e mettere B, in questo caso ricompilerei inutilmente C.

 

Puoi sempre mettere prima B e poi togliere A, in questo caso C non verrebbe comunque toccato  :Wink: 

----------

## Onip

 *emix wrote:*   

> Puoi sempre mettere prima B e poi togliere A, in questo caso C non verrebbe comunque toccato 

 

Daccordo, ma non si fa sempre così. A volte si è sovrappensiero o non si conoscono bene le dipendenze. trovo comunque che un comportamento safe sarebbe meglio per tutti.

----------

## Cazzantonio

 *Onip wrote:*   

> A quando il bug-report comune?

 

Quando ci mettiamo daccordo   :Smile: 

Hai voglia di fare un riassunto che eventualmente si possa commentare?   :Wink: 

Una volta fatto si copia-incolla e si fa un bel feature-request   :Smile: 

----------

## X-Drum

 *Cazzantonio wrote:*   

>  *Onip wrote:*   A quando il bug-report comune? 
> 
> Quando ci mettiamo daccordo  
> 
> Hai voglia di fare un riassunto che eventualmente si possa commentare?  
> ...

 

ottima idea coordiniamoci magari anche su irc o altro

----------

## Onip

 *Cazzantonio wrote:*   

> Hai voglia di fare un riassunto che eventualmente si possa commentare?   

 

La voglia ce l'avrei anche, ma preferisco lasciare la palla a qualcuno un po' più anglofono di me, vista la delicatezza della questione...

----------

## Cazzantonio

 *X-Drum wrote:*   

> ottima idea coordiniamoci magari anche su irc o altro

 

oggi pomeriggio sono su jabber con l'indirizzo che vedi nel mio profilo

----------

## Raffo

Mi raccomando ragazzi, è importante   :Wink: 

----------

## emix

 *Onip wrote:*   

> Daccordo, ma non si fa sempre così. A volte si è sovrappensiero o non si conoscono bene le dipendenze. trovo comunque che un comportamento safe sarebbe meglio per tutti.

 

Si, anch'io la penso così. Basterebbe usare un'opzione aggiuntiva per dirgli di rimuovere pure le dipendenze, tipo:

```
# emerge -C [-D | --deep] pacchetto
```

----------

