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:

[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.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom

[topper_harley]

[cloc3]

[bandreabis]

Sarò io, ma non la vedo tutta sta lentezza di emerge.
_________________
Il numero di post non fa di me un esperto! Anzi!

[cloc3]

[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.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[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]

[cloc3]

[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 ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con

[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).
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[Kernel78]

[Peach]

[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]

[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.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[lucapost]

...
_________________
LP

[lucapost]

[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.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[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?
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom

[morellik]

[cloc3]

[djinnZ]

[cloc3]