linux user group brescia

immagine del castello

Archivio della mailing list

R: R: APT for RPM

Luca Coianiz lcoianux a digitalbrixia.it
Dom 8 Apr 2001 23:43:22 UTC
----- Original Message -----
From: Francesco Dolcini <francesco.dolcini a numerica.it>
> On Fri, Apr 06, 2001 at 03:15:37PM +0200, Luca Coianiz wrote:
    [...]
>>  Domanda: vuol dire che RPM usa le logiche di APT o solo che può gestire
>>i pacchetti .deb ?
> Vuol dire semplicemente che tu come fai con APT ti limiti a dire quale
>programma tu vuoi e lui si limita a trovarti il pacchetto necessario,
> tutti i pacchetti da
> cui dipende, installarli nel giusto ordine.
> I pacchetti non li installa direttamente apt ma dpkg, che e' il tool di
>gestione dei .deb

 Sbaglio o pure Red Carpet dovrebbe fare una cosa del genere ?

>>  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) ?
> Mmmm
> Puoi fare quello che vuoi, tutti tool sotto licenza gpl, attualmente
> ognuno
> debian difende apt e la sua gestione dei pacchetti (ed effettivamente
> funziona molto bene) e red hat difende rpm, considera che e' di certo il
> formato di gestione pacchetti piu' diffuso ....

 Capito: abbiamo un formato molto diffuso (Rpm) al quale mancano delle
feature che invece ha un formato meno diffuso ma migliore.

>> 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)).
> Mi sembrano solo tante parole queste ...

 Beh... è vero: non essendo un programmatore è ovvio che la mia è solo
teoria.
 E me ne dispiace: preferirei saper FARE le cose, anzichè parlarne più o
meno a vanvera. ;o)

 Diciamo che, in fin dei conti, può anche fregarmene piuttosto poco se
RedHat sviluppa Rpm per "raggiungere" Apt sulle feature che mancano e se il
team di Apt fa altrettanto per quello che manca a questo prodotto (ammesso
che ci sia qualcosa che manchi).

 Parlando in senso generale (e teorico) pensavo che il fatto di lavorare su
un prodotto univoco, standardizzato, potesse farlo crescere più velocemente,
smorzare gli entusiasmi relativi alle varie distro ed anche sgonfiare la
rilevanza commerciale di un formato di distribuzione dei pacchetti rispetto
ad un altro (e penso che questo sia il gradino più ostico alla
standardizzazione del formato: ogniuno tenterà di proteggere il suo
mercato).

> prendere il meglio da ogni parte sarebbe una cosa senza senso secondo me,
> scrivere software costa tempo, e scrivere un software copiando da qua e
> la produrebbe un qualcosa di piu' arretrato dei due messi assieme secondo
> me, che nel frattempo si sarebbe entrambi evoluti a qualcosa di meglio
> della loro somma ...

 E' probabile che io mi sia spiegato male: NON parlavo di riscrivere, io o
tu (o un nuovo team di sviluppo) un soft "migliore di Rpm e di Apt"
raccogliendo routines dell'uno e dell'altro e facendo un merge (questa è 'na
cavolata anche per me).
 Parlavo piuttosto di una collaborazione dei due team originali onde
ottenere un prodotto "fuso" che segnasse lo standard del settore e che fosse
poi sviluppato in continuazione e diffuso sia da Debian che da RH.
 Un qualcosa (una "killer application") per cui chi scrive software (tu per
esempio) non fosse obbligato alla scelta "adesso lo impacchetto in una
tarball, in un .rpm o in un .deb ?" ma potesse usare lo standard (ad es.
.pkg) e ritrovare il suo soft distribuito in Debian, RH, Caldera, SuSE,
Slackware, Mandrake, ecc.

        Bye
        Sky






Maggiori informazioni sulla lista Lug