linux user group brescia

> > Un esempio:  tempo addietro il "telnet" era tutto contenuto nel
> > pacchetto "telnet.rpm" (sia la componente server che la componente
> client).
> > Ora RedHat ha deciso di dividerlo in "telnet.rpm" e "telnet-server.rpm",
> > con il vantaggio che ora e' possibile installare il solo "client" (non
> > che io lo farei, intendiamoci, ma per una workstation gestita da uno
> > che viene dal mondo windows puo' essere utile).
> > Con un formato di pacchetti unificato, chi farebbe una tale scelta?
>
>  Mettiamola così: in teoria non ci dovrebbero essere problemi se una distro
> riporta telnet.pkg contenente, storicamente, tutto (client e server), come
> non ci dovrebbero essere problemi a distribuire telnet-client.pkg e
> telnet-server.pkg: è una scelta che il singolo distributore può fare (anche
> se personalmente farei riferimento al team che sviluppa il pacchetto, o la
> serie di pacchetti, in cui è compreso Telnet).

Gia', ma se poi caio fa un pacchetto che dipende da "telnet", ha bisogno
di avere a disposizione una scelta standard...
In altre parole, proprio per agevolare caio che scrive un pacchetto
(deb o rpm) e' necessario che la strutturazione dei pacchetti sia
piu' o meno standardizzata, e quindi tizio NON e' libero di decidere
lui come pacchettizzare "telnet", e la scelta viene fatta a livello
di distribuzione.

Il discorso si sposta quindi a quello di decidere "a livello di standard"
come pacchettizzare certe cose.  Un po' quello che e' successo per la
struttura del filesystem, che alla fine ha portato allo standard FHS
(filesystem hierarchy standard) (correggetemi se dico cavolate).

D'altra parte quando esce uno standard e' giocoforza che alcuni lo stiano
gia seguendo ed altri no, senza peraltro colpa alcuna di questi ultimi,
che magari avevano fatto scelte del tutto ragionevoli che pero' per
una ragione o per l'altra non sono state (poi) incluse nello standard.

E' una delle ragioni per cui il passaggio da RH6.2 a RH7.0 e' doloroso:
la RH7.0 rispetta ora lo standard FHS.

Ti chiederai, ma perche' non lo aveva supportato anche prima?  Semplicemente
perche' lo standard non esisteva ancora.

>  L'importante è che le dependencies siano soddisfatte per il singolo
> componente.

E' appunto questo il nodo, probabilmente.  Penso che proprio per alleviare
i problemi di decisione su come pacchettizzare il formato rpm permette
anche dipendenze da files, oltre che dipendenze da pacchetti.

mp