linux user group brescia

immagine del castello

Archivio della mailing list

R: APT for RPM

Luca Coianiz lcoianux a digitalbrixia.it
Ven 6 Apr 2001 13:15:37 UTC
----- Original Message -----
From: Francesco Dolcini <francesco.dolcini a numerica.it>
> On Mon, Apr 02, 2001 at 12:54:07AM +0200, Luca Coianiz wrote:
>>  Da RPM posso passare ad APT ? non credo (i formati dei pacchetti sono
>> diversi)
>>  E da APT ad RPM ? (stessa risposta, giusto ?)
>E' stato fatto il port di apt a rpm ...
> http://www.conectiva.com/

 Ottimo :-)
 Domanda: vuol dire che RPM usa le logiche di APT o solo che può gestire i
pacchetti .deb ?
(stessa domanda per APT ovviamente: usa anche logiche RPM oppure gestisce i
pacchetti .rpm ?)

 Traduzione: vuol forse dire che in un futuro non troppo lontano (o magari
già adesso) ci troveremo a gestire i pacchetti con uno strumento comune che
prende il meglio di Rpm, Apt e di altri (che indubbiamente ci saranno) ?

 Per me sarebbe magnifico: vorrebbe dire che i team di sviluppo
lavorerebbero assieme invece che in competizione: in fondo Linux non è nato
forse dalla collaborazione piuttosto che dal suo contrario ?

 Personalmente sono piuttosto preoccupato dal fenomeno "distribuzioni" e da
tutto il "campanilismo" che si è sviluppato attorno ad esse: come ho già
avuto occasione di dire, ritengo che le distro dovrebbero al massimo
diversificarsi per particolari funzionalità (ad es. una distro "Knox"
potrebbe essere particolarmente versata nello sviluppo ed implementazione
della sicurezza, ecc. ecc. non sto a ripetere) mentre i vari team di
sviluppo dovrebbero collaborare sugli argomenti generali (network, security,
package handling, filesystem, ecc.).

 Il lavorare in competizione, anche se a volte può portare a qualcosa di
buono (soprattutto quando la competizione è agli inizi, v. anche il caso
KDE/GNome), alla lunga tende a creare due effetti non proprio benefici:

 (1) il proliferare di "dialetti" non del tutto compatibili fra loro. E' già
accaduto, parecchi anni fa in ambito Unix e sta accadendo adesso per quanto
riguarda la distribuzione dei pacchetti installabili: come diceva
giustamente il Giuzzi, un .rpm per SuSE ha probabilmente dipendenze diverse
da uno per RedHat e questo mi sembra un male.

 (2) dato che la competizione tende a spostarsi sul lato commerciale e che
questo, inevitabilmente, significa soldi (a volta TANTI soldi) rischiamo di
impelagarci nell'"effetto Windows": arriva un punto in cui, pur di uscire
con un prodotto nuovo da inserire nella distro che va in vendita, i gestori
delle stesse inseriscono anche prodotti instabili che poi reclamizzano con
"Questa distribuzione contiene anche il nuovissimo KDEFGHI v6.5 !!!".
 A questo punto io, utente inesperto, leggo che la RedHat ha il prodotto
KDEFGHI v6.5 "nuovissimo, bellissimo, biondissimo e ricchissimo", vedo che
la Caldera distribuisce invece ancora la v5.0 e, nella mia ignoranza, cosa
faccio ? Ovviamente compro la RedHat (NASDAQ RH)... e m'impelago con 'sto
prodotto KDEFGHI 6.5-ALFA !!! e non mi passa più, dato che crasha ogni 3 x 2
(mentre Caldera, o Debian, distribuivano una 5.0 STABILE, anche se di sei
mesi fa).

 Questo perchè anche Linux, è innegabile, sta diventando un fenomeno di
massa non solo come server ma anche come client (tanto che Microsoft ne ha
paura e sta tentando di screditarlo in tutte le salse: da benchmark truccati
a buchi di sicurezza fino a combattere l'Open Source stesso dicendo che è un
pericolo) e, nonostante il lavoro dei vari LUG e quanto si scrive nelle ML,
ci sarà proporzionalmente sempre meno gente che capisce la differenza tra
una versione alfa, una beta ed una stabile.

 Quindi, concludendo 'sto pò pò di filippica, personalmente sono favorevole
ad una distribuzione contenente il meglio dei pacchetti sviluppati (NON i
pacchetti migliori ma il meglio della fusione tra i pacchetti: ad es. RPM +
APT = PKM, PacKage Manager (nome a fantasia), KDE + GNOME = TDM, The Desktop
Manager (altro nome a fantasia)).
 Questo non per mortificare i programmatori costringendoli a rientrare in
determinati canoni, per carità: lo sviluppo dev'essere libero. Però sarebbe,
penso, un vantaggio per il popolo Linux se le novità non venissero
sparpagliate in migliaia di prodotti tutti simili che differiscono l'uno
dall'altro per poche particolarità (e che, solitamente, trovi in distro
diverse).

 Ho sentito accennare ad una "Standard Base" ma non ho mai approfondito: per
caso si tratta di qualcosa tipo quello che scrivevo sopra ?

>>  E allora perchè cavolo i due team di sviluppo non si uniscono per creare
un
>> tool migliore di RPM ed anche di APT ??!?
>> (e NON mi venite a dire, anche se non lo conosco, che APT non si può
>> migliorare !)
> Effettivamente come si e' cecato di fare per avere una struttura uniforme
> nel filesystem, e in altre cose, fra le varie distribuzioni cosi si
> potrebbe fare con il meccaniscmo di gestione dei pacchetti?

 Probabilmente sì: se gli sviluppatori di APT e di RPM mettessero insieme le
due tecnologie ne beneficeremmo tutti.
 Non sto parlando di unire prodotti fondamentalmente diversi tra loro come
potrebbero essere Emacs e Diald (chissà che aborto ne uscirebbe: un Emacs
che gestisce le connessioni dial-on-demand oppure un Diald che permette di
editare i file... bah): sto parlando di riunire, prendendone il meglio, quei
prodotti che fanno tutto sommato le stesse cose.
 Non è forse la base dell'Open Source: prendere un pezzo di codice utile,
sviluppato da altri, e creare con esso un'applicazione migliore ?

> O sui tool di amministrazione e configurazione ? tipo linuxconf e yast?
mah

 Assolutamente sì: in fondo devi configurare, mica fare il caffè no ?  :-)

 In generale sarei molto più scontento se un determinato software, ad es.
RPM, ne "eliminasse", per vari motivi, un altro: quelli di APT non saranno
mica dei coglioni no ? Avranno pure avuto i loro bei motivi per non seguire
la strada RPM.
 E ti pare giusto che RPM, magari per motivi commerciali, renda obsoleto APT
?
 E succede, se un miliardo di persone usa RPM e solo dieci usano APT: non ti
pare giusto che parti di APT e parti di RPM confluiscano in un software
migliore di entrambe ? (con piena soddisfazione di tutti e due i team di
sviluppo)

> E allora a questo punto che cosa cambierebbe da una distribuzione
all'altra?
> L'assistenza?
> La "follia" nelle scelte dei pacchetti oppure la loro prudenza?
> La velocita' con cui rilasciano i pacchetti aggiornati da eventuali bug?
> ma se usano la stessa gestione dei pacchetti, la stessa struttura del
> filesystem e dei tool di configurazione come viene fatto un pacchetto
> tutti ce l'hanno ... mah

 Giusto, vediamo un pò quello che differenzia i vari distributori, parlando
in termini di Valore Aggiunto:

- L'assistenza: è sicuramente il prodotto di maggior rilievo. Uno dei
parametri di scelta tra una distro e l'altra dovrebbe scaturire dalla
domanda: "la uso per giocare, per sviluppare software, per mettere online
dei servizi o altro ?". A seconda della risposta andrebbe scelto un diverso
livello di assistenza.

- La presenza di tools che vanno oltre la Standard Base: è più o meno la
stessa risposta di cui alla domanda precedente.

- La presenza di software instabile inserito "il prima possibile" piuttosto
che la stabilità di tutto l'insieme: non vedo modifiche nella domanda posta
inizialmente (e relativa risposta).

 E allora, se la domanda e la risposta sono sempre più o meno le stesse,
perchè dovrei avere una molteplicità di risposte in termini di distribuzioni
?

 Faccio un rapidissimo esempio di distro "come le intendo io" (quindi
sicuramente sbagliato ;-)))):

- Games: distribuzione "Standard Base" + librerie, pacchetti e tools
dedicati ai giochi.
- Developer: SB + tools particolari per sviluppatori (IDE, RAD, Debuggers,
ecc.).
- Server: SB + tools per installare server (molto net-oriented)
- Client: SB + pacchetti tipo StarOffice (e senza troppi tools di sviluppo)
- Standard: SB

 In pratica il distributore dovrebbe preoccuparsi, oltre che a garantire
determinati livelli di assistenza (più alti in caso di Developer e meno
elevati in caso di Client) solo del "delta" che differisce dalla Standard
Base.
 Questo però non vuol dire che il delta stesso dev'essere incompatibile da
una distro all'altra: uno deve potersi creare, se lo ritiene necessario una
distro mista (ad es. potrebbe ever senso una Game+Developer, no ?)
acquistando una distro ed aggiungendo solo il delta di un'altra (e godendo
del livello di assistenza prestato ad entrambe).

> Rimango perplesso, anche perche' non ho cosi esperienza con
> le varie distribuzioni, ne ho provate varie, ma ho usato
> seriamente solo red hat, e ora uso debian, che secondo me
> risulta terribilmente piu' semplice da gestie rispetto ad
> una red hat! sul discorso del risparmiare tempo ...

 Domanda: per passare da RH a Debian hai forse dovuto reinstallare tutto ?
(o magari le usi su sistemi diversi)

>> rpm/apt: è generico e va bene un pò per tutto, anche per YAST e
linuxconf,
>> ecc.
> spero di non essere finito a risponderti proprio quello che tu non volevi
...

 Credo che sia finita proprio così.  ;-))))

> o magari avere scritto cose stradette ;-)

 Ecco... questo lo spero anch'io (delle mie ovviamente). ;-)
(ed essendo praticamente un newbie non me ne meraviglierei)

        Bye
        Sky





Maggiori informazioni sulla lista Lug