paludis vs portage vs pkgcore

[lucapost]

Portage negli ultimi mesi ha fatto diversi passi avanti, dovrebbe essere imminente il rilascio della versione 2.2.
Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.

Ai tempi bui di portage, utilizzai per diversi mesi anche paludis, che poi abbandonai in quanto era in pieno sviluppo e "conveniva" stare dietro i troppo frequenti aggiornamenti.

Invece, no strumento che non ho mai provato ma che tutt'ora mi incuriosisce è pkgcore.

Queste sono le versioni disponibili oggi:

Code: Select all

[I] sys-apps/portage
     Available versions:  [P]2.0.51.22-r3 [P]2.1.1-r2 2.1.4.4 2.1.4.5 ~2.1.5.6 ~2.2_rc11 (~)2.2_rc12 {build doc elibc_FreeBSD elibc_glibc elibc_uclibc epydoc linguas_pl selinux userland_GNU}
     Installed versions:  2.2_rc12(01:12:56 PM 10/10/2008)(-build -doc -epydoc -linguas_pl -selinux)
     Homepage:            http://www.gentoo.org/proj/en/portage/index.xml
     Description:         Portage is the package management and distribution system for Gentoo

* sys-apps/paludis
     Available versions:  ~0.26.2 ~0.28.0 ~0.28.1 ~0.28.2 ~0.30.0 ~0.30.1 {bash-completion doc glsa inquisitio pink portage python qa ruby vim-syntax visibility zsh-completion}
     Homepage:            http://paludis.pioto.org/
     Description:         paludis, the other package mangler

* sys-apps/pkgcore
     Available versions:  ~0.4.7.4 ~0.4.7.5 ~0.4.7.6 ~0.4.7.7 ~0.4.7.8 ~0.4.7.11 ~0.4.7.12 {doc}
     Homepage:            http://www.pkgcore.org
     Description:         pkgcore package manager

Avete opinioni/commenti/esperienze da riportare?

[Peach]

io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.
che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?

gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.

[topper_harley]

io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.
che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?

gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.

Stando a sentire ciaranm pkgcore è terribilmente rotto, porta alla devastazione del sistema, diarrea, vomito, peste e tifo... (a dire il vero pensa lo stesso anche di portage, peste compresa)

http://www.nabble.com/EAPI-2-is-brokened-:(-td19905090.html

[cloc3]

Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.

secondo me, portage non sarà mai veloce.
guai se lo fosse: la velocità nella risoluzione delle dipendenze decresce esponenzialmente con il numero degli ebuild disponibili.
una sua piccola variazione determina un rallentamento sensibile di emerge.

se vuoi un segnale, come chiedevi nell'altro post, gentoo comincerà davvero il proprio declino il giorno in cui emerge sarà diventato un programma veloce.

[bandreabis]

Sarò io, ma non la vedo tutta sta lentezza di emerge.

[cloc3]

Sarò io, ma non la vedo tutta sta lentezza di emerge.

ma infatti, la questione è controversa.
la cosa dipende da troppi fattori diversi dalla qualità del software.

oltre ai problemi di efficienza dell'accesso fisico al filesystem (portage, volutamente, è un database collocato nei file), emerge rallenta in particolare se il file world contiene troppe voci, o peggio, ne contiene di superflue a causa di qualche pacchetto riemerso senza l'uso dell'opzione -1.
oppure se la cartella /etc/portage e la variabile USE di /etc/make.conf sono particolarmente complesse.
cose queste che interessano chi conserva la propria installazione da lungo tempo, magari da anni, senza reinstallare e modificando frequentemente il proprio assetto e aggiungendo di continuo nuovi overlay.

in pratica, la lentezza di portage è figlia della propria versatilità e della propria stabilità.

[djinnZ]

ehm... non per fare il bastancontrario ed indulgere nella mia solita crociata anti-prof... ma hai torto

python non è certo performante quanto un eseguibile; avere quel marasma di file e subdirectory non aiuta:
se inserisci il supporto a psyco, pysql e metti portage su squashfs e la differenza ti salta all'occhio già al primo emerge system, non su una "vecchia" installazione desktop;
se poi (a parte la locazione quantomeno infelice) metti /var/db/pkg su ram (per test, non è una operazione raccomandabile) ti spaventi della differenza.
per non dire del fatto che se vedi cosa c'è in /var/db/pkg/categoria/pacchetto restyi un tantino basito dall'uso di un file per ogni variabile e finezze simili.

Per non dire delle rogne che comporta avere python come dipendenza (a questo punto si poteva pensare, per il gorsso della struttura a bash+eseguibili dedicati per la ricerca, sul modello di q, almeno sarebbe stato assolutamente portabile).

Non sono un fanatico di paludis ma ci sono i problemi. Di certo non mi pare che nessuno si preoccupi di risolverli e si pensa ancora a chi è più bello e più figo.

[lordalbert]

ma per lentezza intendete soltanto la risoluzione delle dipendenze?
In quel caso l'ho notata anche io.... ma per il resto...

Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage? Intendo, se si fosse usato un linguaggio compilato probabilmente sarebbe stato un poì più veloce....

[cloc3]

se inserisci il supporto a psyco, pysql e metti portage su squashfs

questi sono fatti noti, soprattutto per lucapost.
ma lui forse non desidera sbattersi a fare lo script che comprime di notte lo squashfs, oppure apprezza la comodità del database rw nei files.
ora, l'unica alternativa attuale è probabilmente proprio paludis, che però è troppo votato allo sviluppo, che dicono non essere così miracoloso nelle situazioni complesse, nemmeno sul piano della velocità e che lui comunque afferma di avere spontaneamente abbandonato.
pkgcore ... è scritto in python.

perciò al momento è necessario rassegnarsi al fatto che gentoo non è solo portage, fermo restando che comunque portage non è neppure strumento così rudimentale da doversene sbarazzare troppo di fretta.

[cloc3]

Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage?

Drobbins ha voluto un linguaggio di scripting.
lo riteneva più flessibile e maneggevole. e probabilmente riteneva effimero ed irrilevante il vantaggio legato all'adozione di un linguaggio compilato, tant'è che non ha mai considerato seriamente di discutere di questa scelta.

per quanto riguarda la collocazione nel file system, prima di tutto, risolve un problema di dipendenze più grave che quello del python.
ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?
ma soprattutto, hanno avuto un peso le attese che Robbins nutriva nello sviluppo dei filesystem di Reiser (e dei filesystem linux in generale). perciò le "finezze simili" che dice djinnZ, come riservare un file per ciascuna variabile non sono ingenuità imperdonabili di un programmatore in erba, ma rappresentano l'esperimento di qualcuno che spingeva la sguardo un passetto più in là di quanto noi stessi, tutt'oggi, sappiamo vedere.

piuttosto che impegnarsi a riscrivere portage, gli sviluppatori di gentoo farebbero bene a spingere lo sviluppo in questa direzione: quella dei filesystem.

[Kernel78]

ognuno ha le sue priorità e se qualcuno si lamenta di qualcosa allora questa rappresenta un problema, almeno per lui.

Io me ne frego altamente della velocità di risoluzione dipendenze, tanto sul tempo di compilazione non influisce che per una frazione insignificante ...

Per quanto riguarda gli aggiornamenti avevo scritto un post su come ottimizzare il sync notturno e mi invio via mail il diff-eix (così vedo quali pacchetti sono aggiornati) e anche un pretend dell'aggiornamento così posso valutare se devo sistemare qualche USE, mascherare o smascherare qualche pacchetto prima di procedere. Poi prima di andare in ufficio lancio l'aggiornamento effettivo e tanti saluti al tempo di risoluzione dipendenze.

Mi rendo conto che magari questa latenza possa costituire una noia per chi sperimenta, prova e riprova nuovi pacchetti più volte al giorno ma oggettivamente non mi sarei immaginato che questi costituissero una fetta così abbondante ...

[djinnZ]

@kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.

@cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.
In generale il python si è evoluto peggio del perl e comunque non sto a giudicare a posteriori le scelte di robbins ma la mancata revisione del database e della cache da parte di chi è venuto dopo di lui (e dal non voler affrontare l'incogruenza di certe impostazioni tradizionali della destinazione di var home tmp ed etc).
Usare un singolo file per le variabili è un esempio (e non credo che shell o da python complichi le cose, anzi).

[Kernel78]

@kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.

personalmente anche quando installo nuovi sw il tempo di risoluzione delle dipendenze mi risulta trascurabile se confrontato con quello della compilazione ...
oggettivamente penso che la maggior parte del tempo d'uso di un sistema gentoo non sia dedicato all'installazione di nuovi sw quindi il tempo dedicato alla risoluzione delle dipendenze sia irrisorio (a meno che non usiate una macchina solo per creare pacchetti binari ma anche in quel caso ...)

[Peach]

@cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.

guarda secondo me non è questione di "tradizionalismi"
parlando seriamente, considerando gentoo nel suo insieme ( e quindi non solo come un Desktop-OS ) secondo me, meno dipendenze ci sono meglio si sta. Voglio dire: se anche rimuovi gcc un eseguibile va sempre, ma se rimuovi python... ah sono razzi amari!
Dal suo canto python ha effettivamente la facilità e la comprensibilità paragonabile a quella di un linguaggio naturale, e questo non fa altro che favorire la diffusione di gentoo e quant'altro...
Trovare una via di mezzo? Così come stanno cercando di fare per baselayout? a me non sembra una idiozia, ma è anche vero che io non c'ho mai provato a guardarci dentro.

[oRDeX]

Premetto che non programmo in Python (anche se stanno cercando di convincermi ).
Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.

EDIT:
Da una veloce ricerca mi pare di aver capito che c'è chi ha sviluppato alcuni tool per la compilazione del python in linguaggio macchina: http://starship.python.net/crew/atuining/cx_Freeze/
Non ho finito di leggere il README ma non mi pare ci siano controversie. Ovviamente così si risolverebbero mediamente i due problemi di prima: performance (almeno un minimo) e dipendenza (dall'interprete).

[morellik]

Premetto che non programmo in Python (anche se stanno cercando di convincermi ).
Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.

Ti devo contraddire perche' internamente, il codice sorgente Python viene sempre convertito nella rappresentazione in bytecode, e questo viene dopo eseguito nella macchina virtuale di Python. Non c'e' nessuna differenza a livello di prestazioni una volta che il file .pyc e' stato caricato, come del resto il bytecode letto dal file .pyc e' lo stesso di quello creato dalla conversione diretta. L'unica differenza e' che il caricamento di codice dal file .pyc e' più veloce dell'analisi e conversione di un file .py, per cui la presenza di file .pyc precompilati migliora il tempo di avvio degli script Python.

L'unica alternativa potrebbe essere l'uso di psyco, mi pare di aver postato come fare, ma non so se e' sempre compatibile con l'ultima versione di emerge.

[djinnZ]

Mettendo /var/db/pkg in ram la differenza è notevole, più che usare psyco, pysql e squashfs (o è meglio cram? Non lo ho mai usato per questo chiedo, già che mi trovo).
Però il fatto che debba attendere sempre almeno quei 30 secondi quando lancio un emerge ltrace (l'ultima cosa che ho fatto) mi scoccia, e non poco, più perchè intuisco che scelte frettolose, fatte da drobbins in una fase iniziale, si sono cristallizate.
Non sto dicendo che drobbins ha sbagliato, solo che ha operato alcune scelte, valide in fase di prima implementazione, che non dovevano rimanere tali.

Per non dire del fatto che avere sulla stessa partizione i file temporanei usati per compilare ed il database dei pacchetti è una spada di Damocle che mi impensierisce non poco; su filesystem come xfs ti ritrovi a terminare il flush della cache e cancellare i file temporanei (e su xfs è da sempre lenta come operazione) e scrivere il database contemporaneamente. Vero che avevo formattato con impostazioni eccessive, tanto era il disco di prova, ma mi sono trovato più volte con il database irrecuperabile, lo ripeto.
Però per quanto riguarda var ci sarebbe da discutere che log, fax e via dicendo non hanno la stessa importanza ed utilità di cache e temporanei vari, ma se penso a quel che sono le espressioni regolari (sia sempre maledetto l'idiota che si è inventato "* *" nella linea di comando) non mi stupisco più di tanto.

Se il python si fosse evoluto senza incompatibilità e problemi (o meglio se non si fosse mai evoluto come il bash scripting) poteva anche andar bene.
Di sicuro elementi come l'init (motivo per il quale non sono passato ad einit, la dipendenza da expat), il gestore dei pacchetti nelle sue funzioni principali (ovvero aggiornare il sistema ed installare/disinstallare), la shell etc. devono avere dipendenze minime o nulle, sia a runtime che in compilazione.

Per esempio a cosa serve la funzione di ricerca in emerge? Non è una cosa che è meglio lasciare ad un pacchetto esterno come eix/q?

Paludis mi pare che voglia ripercorrere lo stesso errore (anzi peggiorarlo e senza la facilità di un linguaggio interpretato) e quindi mi piace poco.

[lucapost]

...

[lucapost]

ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

e cosa ci sarebbe di così male? per gestire quasi 13000 pacchetti..., finchè il necessario mi passa in 700mb per l'installazione....

se da qualche parte si andrà a finire, IMHO, si finisce ad un database oppure si spezzerà l'albero di portage perlomeno in overlays di progetti minori. chi vivrà vedrà...

[djinnZ]

una lettura del buon vecchio knuth o del buon Nick Wirth non farebbe male.
Prima si progetta la struttura dei dati e poi si inizia a scrivere il programma, soprattutto quando si aggiunge.

Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol non c'era neppure il C64 in commercio e quando scrissi l'ultimo in c M$ non era ancora imposta per legge, un tantino arretrato lo sono) ma non ho mai letto niente da parte dei devel sul portage, solo implementiamo questo, implementiamo quello.
Ammetto che c'è chi spinge il discorso solo in quella direzione ma in ogni caso non va.

[Peach]

vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?

[morellik]

vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?

E' vero, Python 3.0 non sarà retrocompatibile (non starò a discutere su una strategia che secondo me è giusta. Ogni tanto occorre dare un colpo di spugna per far funzionare al meglio le cose.). Ma Python non è M$ che decide da un giorno all'altro smettere di darti un SO in favore di un altro. I developer Gentoo avranno tanto di quel tempo per adattarsi ai cambiamenti che ci potrebbero invecchiare. Oltretutto più versioni di Python possono convivere tranquillamente senza alcun fastidio.

Il tutto IMHO.

Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol ...

Cobol Quanti ricordi....Il mio primo corso di programmazione...... Grande djinnZ, allora non sono l'unico "vecchio" in questa baracca.

[cloc3]

ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

e cosa ci sarebbe di così male?

me lo chiedi?

intanto, il database non rende più celere il calcolo delle dipendenze. il database sveltisce solo l'accesso ai dati necessari per risolvere le dipendenze...

ma come minimo, se i dati sono inclusi in un database, serve un programma per navigarlo.
al momento il mio browser preferito per navigare portage è ls, in linea di comando.
sono sicuro che sia molto più facile scoprire un programma nuovo così che usando synaptics o qualunque altro gestore di pacchetti strafico della distro più in voga.

e al di là di ogni giudizio tecnico, apprezzo in questo un valore immenso di libertà.
infatti, il database chiuso impone un rapporto privato con l'utente che gentoo risolve con straordinaria leggerezza.

infine, considerato che stiamo parlando di gentoo, è evidente che quel browser non potrebbe funzionare meglio di un certo installer grafico di nostra infelice memoria .
anche un pizzico di realismo e/o di sano umorismo... quando ci vuole ci vuole.

[djinnZ]

intanto, il database non rende più celere il calcolo delle dipendenze

una base dei dati decente ben strutturata rende più veloci le operazioni. Per età ed in virtù del lavoro knuth e wirth li devi conoscere...

[cloc3]

intanto, il database non rende più celere il calcolo delle dipendenze

una base dei dati decente ben strutturata rende più veloci le operazioni.

la struttura del database di portage è decente. infatti tu dici che, caricato in ram, è una scheggia.

knuth e wirth? purtroppo no. la mia è una cultura di nubbio maneggione.