[gl-como] Distrø

[Nicola Viganò]

Il 07/09/2011 13:46, Matteo DarkFlash ha scritto:
> Packo e` molto diverso da pacman...
> 0. Si vorrebbero supportare piu` architetture di x86 e amd64
> 1. E` scritta in ruby
> 2. Supporta molti piu` kernel di arch
> 3. Ha un sistema di aggiornamenti diverso (si pensa di fare una rolling
> release ed anche un ramo stable)
> 4. Ha un sistema di repository diverso
> 5. Puoi scegliere se compilare (utilizzando un sistema simile a quello
> di gentoo configurabile con use flags, cflags, cxxflags e quant altro) o
> se installare pacchetti gia` compilati
> 6. Utilizza un sistema di tag dei pacchetti
>
> il file unico di configurazione imho e` una buona idea, ma non e` quello
> che la rende una copia di arch.
Come ogni progetto agli inizi ha sicuramente un vantaggio: poter ancora
fare delle scelte strutturali radicali, senza doversi mantenere in
schemi consolidati.
Riflettendoci bene, questo potrebbe esser anche un rischio. Quando si è
agli inizi, non si sa bene ancora che direzione prendere e si potrebbe
rischiare di fare scelte pesanti.

Vedo molte cose che prendono più da Gentoo che da arch.
Gentoo supporta architetture di tutti i tipi, kernel/libc di vari tipi,
compilatori (eh si pure quello!) di vari tipi, etc.
Gentoo è rolling, con rami stabili, instabili, hard-masked e la
possibilità di mischiare il tutto a piacimento.
Gentoo permette sia di compilare che di usare i bindist, ossia pacchetti
precompilati.

Per quanto riguarda il repository, o forse intendi l'albero dei
pacchetti, non so come funzioni su distro, quindi non posso far un paragone.
Come non so cosa possa portare di più un sistema di tag ai pacchetti.

Siccome l'esperienza insegna, vorrei questionare alcune delle
scelte/vanti di distro, alla luce di quanto si è imparato con Gentoo.

La scelta di ruby come linguaggio per la gestione dei pacchetti potrebbe
non esser la migliore. Ammetto che per certi task non si può sempre far
tutto in C e C++, ma l'esperienza insegna che anche un linguaggio come
python, che alle volte è provvidenziale, può risultare poco efficiente
alla lunga.
Ruby, per quel poco che ne so, ha lo svantaggio di esser un linguaggio
troppo libertino e con la tendenza a far diventar il codice estremamente
"messy".
In questo mi ricorda proprio python, che con i suo sugar sintattici, può
esser affascinante per far le cose in fretta, ma estremamente deleterio
a lungo andare.

Portage ha un percorso un po' travagliato di recente proprio per questi
motivi appena elencati. Motivi che sono quindi determinanti nella
nascita di progetti come paludis (sostituto di portage scritto in C++).

Anche il supporto a multipli kernel/libc e architetture non è
necessariamente un vantaggio. Se il team di sviluppo è limitato,
significa solo disperdere le forze.
Per poter mantenere i pacchetti, e sopratutto mantener la consistenza
del sistema con gli aggiornamenti non è un lavoro semplice.

Ci sono pacchetti che possono fallire la compilazione (o il
funzionamento) in seguito all'aggiornamento di un altro pacchetto. Per
chi non ha ed utilizza costantemente tutto il ramo che mantiene, questi
breakage possono passare inosservati, con conseguente irritazione da
parte degli utenti.

Una distro rolling e from sources, è uno sforzo immane. Penso che
pensare troppo in grande fin dall'inizio non sia necessariamente un
punto a favore :)

Infine un'altra nota sul packet manager, che a quanto vedo è basato su
git. La cosa è sicuramente una bellissima idea sulla carta.
Ho provato ad usare funtoo proprio per questo motivo. Purtroppo questo è
stato anche uno dei motivi per cui sono scappato a gambe levate da
funtoo, per tornare a gentoo.
Col tempo, lo spazio occupato dai pacchetti aumenta a dismisura.
Per qualcuno che come me, tiene l'albero dei pacchetti usa in file
formattato e montato come loop device, per poter diminuire al massimo la
frammentazione e migliorare i tempi di accesso all'albero, git è una
soluzione terribile!!

Inoltre, l'utilizzo di git richiede parecchio tempo per rimetter in
sincrono l'albero e la sua cache, quando non si sincronizza ogni 6 ore:
su distro grosse, le modifiche all'albero dei pacchetti sono veramente
molte ogni giorno! git deve aggiornare tutta la cronologia, mentre con
rsync, si copia solamente lo stato finale dell'albero!

Mi dispiace smontare tutto, ma sono sicuro che capirai le mie buone
intenzioni nel volerti esporre i problemi, senza voler criticare una tua
scelta.
Di sicuro, più problemi si hanno e più si impara. Quindi se ti piace
l'idea buttatici dentro!!