Osservando le modalità che permettono di installare software in GNU/*/Linux mi torna in mente la famosa frase di Tanenbaum secondo cui la cosa bella degli standard è che ce ne sono molti tra cui scegliere ![]()
Abbiamo la compilazione da sorgenti, la compilazione tramite port, i pacchetti precompilati ( rpm, deb, tgz ), i pacchetti custom resi disponibili da terze parti ( gli installer NVIDIA, per esempio ) ed infine i sistemi distribution-indipendent come Klik, Autopackage e Zero-Install.
Questa situazione non è un problema per gli utenti con esperienza, che sono in grado di prendere autonomamente le decisioni, tuttavia, per un nuovo arrivato nel mondo GNU/*/Linux, installare software può diventare un’impresa difficile, soprattutto se quello che si cerca non è incluso nei repository o pacchettizzato per la propria distribuzione. Visto che nei giorni scorsi abbiamo parlato sia di Klik che di Autopackage ho pensato che fosse carino segnalarvi questo pezzo di Polishlinux, che prova a riassumere alcuni degli sforzi effettuati per risolvere questo problema ed esaminare il possibile futuro della pacchettizzazione di software in GNU/*/Linux.
[ via Slashdot ]
gandoo
24 feb 2007 - 13:55 - #1Il dio apt fa tutti i miracoli possibili :D
ossmc
24 feb 2007 - 16:09 - #2@gandoo
non che voglia fare il polemico, ma apt non è lo strumento che risolve tutti i problemi: e parlo sia delle questioni tecniche (mancano multiarchitecture, multiversion, possibilità di un downgrade controllato ben fatto, controllo di integrità dell’installazione, etc…) sia delle questioni “politiche” - c’è una certa convenienza da parte delle distro ad essere incompatibili tra di loro, è inutile negarlo o dire “se facessero tutti come la mia distro preferita, il linux sarebbe migliore”.
Mi auguro che LSB sia capace almeno di uniformare il formato dei pacchetti nel prossimo futuro.
manuel
24 feb 2007 - 17:35 - #3Non scordatevi pacman, il miglior manager secondo me.
fabrix
24 feb 2007 - 20:53 - #4apt non risolverà *tutti* i problemi ma è senza ombra di dubbio il migliore, dato che alla fine lo hanno scimmiottato tutti e spesso malamente (qualcuno ha detto yum?). :-)
Più in basso il formato “.deb” ha molte caratteristiche e accortezze in più rispetto a “.rpm”. È inutile negarlo.
Detto questo in pratica giriamo sempre intorno a questi 2 formati base, non mi pare che ci sia tutta ’sta babele.
Per le distro è inevitabile che ognuna favorisca i *suoi* pacchetti (sia deb che rpm) dato che le linee guida, i percorsi sul filesystem, i file di configurazione, le script di pre e post installazione sono specifiche per *quella* distro e spesso incompatibili.
È il prezzo da pagare per la versatilità e la libertà del _free software_ in cambio di enormi vantaggi e soddisfazioni.
Michele Renda
24 feb 2007 - 21:09 - #5Io utilizzo apt, specialmente con la sua interfaccia grafica synaptics, ed e bellissimo. Mi ci sono trovato benissimo, secondo me è la strada giusta da seguire.
Jena Plisskin
24 feb 2007 - 21:29 - #6Non a caso apt ha i poteri della supermucca :-)
ossmc
24 feb 2007 - 21:45 - #7@fabrix
> “apt…alla fine lo hanno scimmiottato tutti e spesso malamente”
Guarda che quando hanno scritto apt nel ‘95 gli update manager esistevano già da quasi dieci anni… unix docet.
> “Più in basso il formato “.deb” ha molte caratteristiche e accortezze in più rispetto a “.rpm”. ”
A cosa ti riferisci di preciso?
A me risulta proprio il contrario, come ad esempio l’assenza del mutiversioning(è un difetto di dpkg, che si riflette in apt), l’assenza del controllo di integrità referenziale (rpm ha db transazionale come back-end, dpkg lavora su liste testuali senza log - che significa che un crash del programma dpkg può far perdere la struttura della distro, in rpm no ed in più rpm può ricostruire il db dal log globale delle operazioni), il controllo di integrità della distro, il supporto da anni degli rpm firmati digitalmente, il sistema di downgrade dei pacchetti: tutte cose che mancano al sistema deb/dpkg. Inoltre la maggior parte delle persone che conosco che usano distro dpkg-based installano spesso pacchetti con il –force, che significa che “stanno buttando via” il package system.
> “È il prezzo da pagare per la versatilità e la libertà del _free software_ in cambio di enormi vantaggi e soddisfazioni.”
Non direi, direi piuttosto: è il prezzo da pagare quando la gestione di un sistema è centralizzata nelle mani di distro che si fanno la guerra invece che nelle mani dei progetti interessati. E questo forse darà enormi soddisfazioni a chi controlla le distro ma non di certo a chi deve usare questo caos di pacchetti/formati/dirtrees/etc…
Riccardo Raneri
25 feb 2007 - 05:06 - #8Tanto per dimostrare la mia enorme autorefenzialità ed il mio egocentrismo, vi invito alla lettura del post sul mio blog:
http://riccardo.raneri.it/blog/index.php/2007/02/06/lettera-aperta-a-linux/
Comunque sia, la necessità di un sistema di installazione davvero standardizzato (e in qualche modo autocompilante, anche se il concetto di autocompilazione nel caso di Linux è, mi rendo conto, un po’ vago e anche in parte utopico) è sempre più urgente.
L’abisso tra la semplicità di installazione e disinstallazione di un programma tra Linux e Windows, MA SOPRATUTTO TRA LINUX E MAC OS X è evidente: una volta superato questo ostacolo, Linux potrà aspirare davvero a diventare un sistema desktop tranquillamente utilizzabile da chiunque.
Come potete capire, non sono molto in accordo con l’idea di Torvalds per cui un sistema operativo studiato per essere utilizzato anche dagli idioti sarà usato solo da… idioti. :)
fabrix
26 feb 2007 - 13:41 - #9@ossmc
> Guarda che quando hanno scritto apt nel ‘95 gli update
> manager esistevano già da quasi dieci anni… unix docet.
be’, cosa c’entra? Stiamo parlando di GNU/Linux, no? Mica di “smitty install_latest” ! ;-)
[caratteristiche e accortezze .deb]
> A cosa ti riferisci di preciso?
per esempio (una cosa tra le tante) al fatto che posso disinstallare un pacchetto lasciando i file di configurazione intatti. Oppure che nei pacchetti deb ci sono molti più campi degli rpm: non solo le dipendenze obbligatorie, ma anche le “consigliate” e molto altro (pinning) ecc…
> A me risulta proprio il contrario,
> come ad esempio l’assenza del mutiversioning
Che intendi? Con debian è possibilissimo installare 2 versioni diverse dello stesso programma…
> l’assenza del controllo di integrità referenziale
> che significa che un crash del programma dpkg può far
> perdere la struttura della distro
non serve, MAI succeso, MAI che si rovinasse una installazione e che si finisse in un vicolo cieco inestricabile (al di là del `backend`). Nel 99% dei casi un “apt-get install -f” risolve da solo la cosa. APT è anche autocurante! Ovviamente non bisogna aggiungere repository “strani” ad-cacchium! ;-)
> il supporto da anni degli rpm firmati digitalmente
anche apt/dpkg li supporta da diverso tempo.
> il sistema di downgrade dei pacchetti
a me sembra che non hai mai usato apt seriamente, esiste una apposita opzione che forza la versione, e se è antecedente a quella attuale ovviamente avviene il “downgrade”.
Non solo, stando un minimo accorti è possibilissimo retrocedere l’intera distribuzione!
> tutte cose che mancano al sistema deb/dpkg.
Non mi pare proprio… :-)
> Inoltre la maggior parte delle persone che conosco che
> usano distro dpkg-based installano spesso pacchetti con
> il –force, che significa che “stanno buttando via” il
> package system.
be’, permettimi ma codeste persone non hanno capito una cippa oppure NON usano repository “sani”. Io sono anni che uso Debian / Ububtu e MAI, sottolineo *mai* ho dovuto usate l’opzione “–force” neanche sulla Debian Unstable pensa!. Al contrario quando usavo Red Hat / Fedora è capitato qualche volta di dover “forzare”.
ciao
[ root@Caserta-GNU/Linux-User’s-Group: / ]# _ &
08 apr 2007 - 07:38 - #10[…] Nonostante Nix possa essere installato su qualsiasi distribuzione ( ed essere utilizzato a-la ZeroInstall / Klik ) i suoi sviluppatori hanno deciso di spingersi oltre e sviluppare una distro che lo utilizzi anche per la gestione dei file di configurazione, dei servizi e del kernel: in NixOS è possibile effettuare il rollback ad una configurazione precedente, non esistono /bin, /sbin, /lib, /usr perché tutto viene archiviato in /nix/store e tutti i file di /etc sono in realtà link che puntano ai corrispettivi in /nix/store. […]