erlug
[Top] [All Lists]

Re: [Erlug] RFC Progetto Didattica

To: erlug@xxxxxxxxxxxxxx
Subject: Re: [Erlug] RFC Progetto Didattica
From: "Ivan Sergio Borgonovo" <mail@xxxxxxxxxxxxxxx>
Date: Fri, 17 Jan 2003 12:25:19 +0100
On 17 Jan 2003 at 10:10, Giovanni Caruso wrote:

> > Forse, trattandosi di Software Libero o Open Source dovresti partire a
> > classificarli dai sorgenti e di questi dire:
> > 1)  le risorse necessarie a compilarli
>
> Si ma in alcuni casi ci sono troppe dipendenze che spesso sono soddisfatte
> (anche se non in toto) dalle installazioni standard. Alla peggio si tratta di

Intendevo risorse HW. Non ti stavo suggerendo di sviluppare una nuova
distro... anche se non mi dispiacerebbe che ci fosse una distro
pubblica (nel senso di sviluppata all'interno del pubblico, Uni, PA,
etc...)

> recuperare qualche pacchetto dai CD stessi.
>       Pensavamo di limitare le informazioni alle eventuali librerie che non
> vengono fornite col pacchetto ma di cui abbiamo dei links (ad esempio lyx,
> che non c'entra nulla, richiede xforms-0.89 ecc.)

mbho... ma questo dipende da che rpm consideri...
se la distro ha compilato con ./configure --without-ssl ed
eventualmente che nome ha dato al pacchetto SSL...)
Non è di tua competenza.

> > 2)  per quali architetture funzionano.

> L'eventuale dipendenza dal desktop grafico (GNOME-vers, KDE-vers)
> sono sufficienti o no?

non c'entra un tubo. Parlo di x86, alpha, sparc, ppc...

> > 3)  se ci sono pacchetti rpm (sorgenti e precompilati) già pronti, dove,
> >     per quali distro e che risorse richiedono per essere installati

> Questo é un problema (che volendo si può risolvere in parte con rpmfind.net)
> ma l'inconveniente é tecnico in quanto:
> 1) molto spesso l'autore pacchettizza:
>       *) l'rpm specificando solo se va su rh (e molto spesso va solo 
> sull'ultima
> versione)
>       *) Il tar.gz (che teoricamente può essere ricompilato su tutte le
> piattaforme)
>       *) l'eventuale pacchetto debian
> Noi vorremmo fornire un servizio del tipo (lo abbiamo provato su:....) e

Puoi, perchè no.
Però parti dal programma, non dal pacchetto e poi del programma dici
quali pacchetti esistono (incluso sorgente) e gli url...

Si cerca per funzionalità, poi uno vuole sapere qual'è il "pacchetto"
che gli darà meno problemi per avere quella vunzionalità.

Eg.
sceglierò l'rpm di rh se uso rh e mi dicono che è stato testato.
scegliero sorgenti se manca l'rpm per SuSE ma mi dicono che i sorgenti
sono stati testati... etc...
e si potrebbero considerare anche i pacchetti non ufficiali...

Così uno sa anche da dove downloadare quello che gli serve.

> abbiamo fatto una cernita di distribuzioni che potenzialmente un insegnante
> se non alle prime armi ma che cmq non é ancora pratico potrebbe iinstallare
> su una macchina a scuola (di certo non si mette la slack :-P)

aspetto qualcuno che dica: perchè no? <g>

> > Mi sembra che la dipendenza dalla versione del kernel (a meno che tu
> > non intenda kernel Linux/BSD/whatever) sia rara.
>
> E' un pensiero rivolto al futuro...nel passaggio da kernel 2.2 a 2.4 é stato
> necessario fare l'upgrade di molti pacchetti per poterlo usare, se non
> addirittura installarsi (a casa) delle distro ex novo....e quando uscirà il
> 2.6?

Non mi sembra tantissimi pacchetti strettamente dipendenti dal kernel.
Quello che mi viene in mente a colpo sono le binutils e iptables (e
roba firewall related)...
Potrebbe essere mia ignoranza ma non mi sembra ci siano molti pacchetti
che dipendono dalla versione del kernel di Linux... mi sembra invece
che ci siano più problemi a essere certi che esista un port per
architettura X o kernel diverso (BSD etc...) di alcuni pacchetti.

> > Anche nei sorgenti parte di queste info potrebbero essere collezionate
> > in maniera automatica anche se negli RPM hanno un formato più standard.
> > Qua potresti integrare la compilazione del DB in maniera automatica da
> > entrambe le "fonti" anche se imposteresti la struttura sui
> > sorgenti/applicazioni e non sui pacchetti.

> Eh?Non ho capito moltissimo.....:-)

Bhe in un rpm ci sono i campi name, version, release, copyright....
Molti README, Makefile, documentazione allegata ai sorgenti contiene
queste informazioni in maniera più o meno recuperabile automaticamente
ma non tanto agevolmente come si può fare leggendo un rpm.

> > E' interessante notare che l'abitudine a pensare a 1) non avere i
> > sorgenti 2) avere un solo punto di riferimento per la distribuzione di
> > un pacchetto 3) una sola architettura 4) un solo OS influenzi la
> > struttura di un DB di questo genere.

> Cosa intendi dire?Ciao e grazie molte del tuo parere

Intendo dire che con il Software Libero hai molta più scelta, molta più
autonomia e molte più informazioni.


--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h


<Prev in Thread] Current Thread [Next in Thread>