Luca Annunziata

UPI, il pacchetto universale

Un progetto italiano per costruire un archivio multipiattaforma di applicazioni. In grado di garantire a tutti i sistemi *nix i programmi che servono, quando servono

Roma - Ci sono volte che si vorrebbe mandare tutto a quel paese. Per installare KDE occorre ricordarsi di aggiornare le librerie collegate e le rispettive dipendenze. Che magari sono diverse da quelle necessarie per Gnome e via così. Tutto questo, però, è ora un ricordo del passato: basta installare Upi-src, l'installer universale di pacchetti realizzato da un team di sviluppatori italiani, per entrare in nuova era in cui i programmi funzionano sempre tutti, e le dipendenze sono solo un brutto ricordo.

La homepage di Upi-src"Sono uno slackwariano - racconta a Punto Informatico Ettore Di Giacinto, ideatore del progetto Upi-src - e mi sono sempre ritrovato con il problema dei pacchetti per la mia distribuzione: l'unico sistema che esisteva era il port di APT get, ma ogni volta finiva che non c'era mai il pacchetto che mi serviva o che ci volevano due o tre ore per riuscire a compilare tutte le dipendenze prima di poter passare al programma principale".

La cosa, spiega Ettore, era seccante: all'inizio ci si passa sopra per via dell'entusiasmo, ma pian piano diventa stancante: "Mi sono detto: sarebbe comodo realizzare un sistema migliore per la gestione dei pacchetti, magari sfruttando le repository Debian dove ci sono tutti i sorgenti. Già che c'ero, ho pensato di farlo per tutti i sistemi operativi".
Upi-src, infatti, funziona su qualsiasi OS del ceppo *nix. Gli utenti di una qualunque distribuzione Linux, di BSD, di Solaris, di HP-UX o di AIX, non hanno problemi ad utilizzarlo: "In teoria funziona pure su Mac OS X, visto che è un derivato di BSD, mancano solo Perl e Cpan e funziona tutto alla perfezione - chiarisce Di Giacinto - Ha qualche limite su BeOS, che richiede una repository a parte per i suoi sorgenti, ma ci stiamo lavorando".

Tutto ciò è possibile grazie al meccanismo di funzionamento: Upi-src non scarica un binario precompilato, bensì scarica un sorgente e avvia la compilazione. Il programma, inoltre, per garantire la massima compatibilità è scritto in Perl: "╚ flessibile, multipiattaforma, si trova ovunque - spiega Ettore - Perl è presente in tutte le distro linux, su BSD basta un comando per installarlo e anche su Mac la procedura non è complicata".

Il tutto risulta comodo: basta scrivere una riga sulla linea di comando per avere la certezza che entro qualche minuto sarà tutto funzionante. "╚ qualcosa di simile ad Emerge, il sistema presente sulla distro Gentoo - racconta Di Giacinto - ma sfrutta una concezione diversa. Upi-src è più veloce di Emerge, perché per l'indicizzazione ho usato un semplice file: trovo che così sia più semplice da manutenere".

Strada facendo, Di Giacinto è anche riuscito a risolvere un problema storico di APT get: il cosiddetto RPM hell, vale a dire la situazione di stallo nella quale il sistema finisce a causa delle dipendenze incrociate tra i pacchetti: "Non sapevo neppure esistesse questo tipo di errore, ma mi ci ero ritrovato davanti ed ero andato in paranoia: poi mi è venuta l'illuminazione ma non avevo un computer davanti. Ho scritto tutto su un foglietto e il giorno dopo ho sistemato il programma: bastava una semplice eccezione da gestire per scavalcare il loop".

Con Upi-src, inoltre, si scavalca anche il problema delle versioni delle librerie necessarie: tutto quello che serve viene scaricato e compilato, senza che si verifichino interferenze tra diversi pacchetti installati in momenti differenti.

"Il nostro attuale problema è la repository" confessa Ettore. Il codice è stato scritto in massima parte e funziona abbastanza bene, ma costruire un archivio di migliaia di pacchetti non è facile: "All'inizio mi ero appoggiato a Debian, ma in quel caso ci sono molti sorgenti che funzionano solo su quella distro perché sono stati adattati, mentre a volte mancano del tutto. Al momento lavoriamo ad una repository tutta nostra, e cerchiamo collaboratori che ci diano una mano a sviluppare il progetto".

A lavorare al progetto, per il momento, sono in cinque. Oltre ad Ettore c'è il suo amico e vicino di casa Francesco Ferretti, poi c'è il programmatore Luca Scianna conosciuto in rete, così come quell'Alessio Porcacchia che è una vecchia conoscenza dei lettori di PI. Infine c'è Mauro Fava che si occupa del betatesting. Ma Upi-src ha anche bisogno di utenti finali: "Abbiamo un sistema di segnalazione che ci avvisa via email quando c'è qualcosa che non va, se c'è un programma che non completa la compilazione: più beta tester ci sono - conclude Ettore - e più il tutto funzionerà meglio, perché potremo intervenire a sanare i problemi".

a cura di Luca Annunziata
71 Commenti alla Notizia UPI, il pacchetto universale
Ordina
  • Esiste un progetto da mille mila anni portato avanti dai maestri del multipiattaforma i signori manutentori dell distribuzione NetBSD.
    Il progetto è Pkgsrc e svolge in modo testato e consolidato dallo stesso tar.gz sorgente di base lo stesso lavoro di questi ragazzi, con le ulteriori features che evito qui di elencare, con attenzione maniacale alla sicurezza e auditing.
    Gira in modo trasparente su Linux, *BSD e OSX + mille mila altre piattaforme embedded sia software che hardware.
    Non ha rivali è l'unica al mondo attivamente sviluppata è anche la base di ottime distribuzioni linux.
    Mi chiedo, che valore aggiunto ho ad usare questa pseudo copia italiana?
    Cosa avro in cambio, rispetto quello che gia ho con pkgsrc, dopo aver investito le mie risorse nel testing and debugging?
    Perche è un lavoro da zero invece che un fork di pkgsrc a valore aggiunto?
    Ciao,

    Luca
  • - Scritto da: LucaCappelletti
    > Esiste un progetto da mille mila anni portato
    > avanti dai maestri del multipiattaforma i signori
    > manutentori dell distribuzione
    > NetBSD.
    > Il progetto è Pkgsrc e svolge in modo testato e
    > consolidato dallo stesso tar.gz sorgente di base
    > lo stesso lavoro di questi ragazzi, con le
    > ulteriori features che evito qui di elencare, con
    > attenzione maniacale alla sicurezza e
    > auditing.
    > Gira in modo trasparente su Linux, *BSD e OSX +
    > mille mila altre piattaforme embedded sia
    > software che
    > hardware.
    > Non ha rivali è l'unica al mondo attivamente
    > sviluppata è anche la base di ottime
    > distribuzioni
    > linux.
    > Mi chiedo, che valore aggiunto ho ad usare questa
    > pseudo copia
    > italiana?
    > Cosa avro in cambio, rispetto quello che gia ho
    > con pkgsrc, dopo aver investito le mie risorse
    > nel testing and
    > debugging?
    > Perche è un lavoro da zero invece che un fork di
    > pkgsrc a valore
    > aggiunto?
    > Ciao,
    >
    > Luca

    vi lamentate perche' gli italiani sviluppano poco quando sviluppano dicono e' una cosa gia' esistente...
    e che invece devo dire io
    che mi aspettavo un commento serio e ho letto uno pseudo-commento come il tuo?
    non+autenticato
  • - Scritto da: LucaCappelletti
    > Perche è un lavoro da zero invece che un fork di
    > pkgsrc a valore
    > aggiunto?

    Luca, la notizia di UPI-src sta suscitando le stesse reazioni da tutte le parti:
    1. perché farne uno nuovo?
    2. for i in pkgsrc emerge emerde pacman ports fink ; do echo "perché non usare invece $i\?" ; done A bocca aperta
    3. perché disperdere le energie?

    E io invece sollevo un perché:
    Perché non si può lasciare che ognuno faccia un po' quel che gli pare?
    E' alla base dell'open source la generazione dei fork, se non si agisse in questo modo staremmo ancora a BSD e Minix.
    Allora, visto che, come per altro diceva "mi fate morire", di progetti italiani ce ne sono pochi per una volta si potrebbe provare a fare i complimenti a chi ha fatto lo sforzo di dare il suo contributo.
    Non si sa mai nella vita, magari Murdock domani vede UPI-src e prende qualche pezzo che finirà in APT (o più probabilmente nel package manager di OpenSolaris (questa era cattiva A bocca aperta)). Ben vengano lo nuove (più o meno) idee.
    Come stiamo dicendo da molto tempo a Torino: ci sono troppi utenti e troppi pochi sviluppatori.

    Developers, developers, developers, developers!!!!! (A bocca aperta)
    non+autenticato
  • - Scritto da: Simoleso
    > Luca, la notizia di UPI-src sta suscitando le
    > stesse reazioni da tutte le
    > parti:
    > 1. perché farne uno nuovo?
    > 2. for i in pkgsrc emerge emerde pacman ports
    > fink ; do echo "perché non usare invece $i\?" ;
    > done
    > A bocca aperta
    > 3. perché disperdere le energie?
    >
    > Allora, visto che, come per altro diceva "mi fate
    > morire", di progetti italiani ce ne sono pochi
    > per una volta si potrebbe provare a fare i
    > complimenti a chi ha fatto lo sforzo di dare il
    > suo
    > contributo.


    Effettivamente ho omesso una premessa di complimenti & co perche comunque è sempre un'iniziativa lodevole che condivido e gli faccio i miei migliori in bocca al lupo!!
    Avendo già da prima di PI osservato il codice perl che sottende il progetto e vista la più che prematura condizione del codice, mi sono meravigliato che addirittura fosse finito come articolo qui!!
    Questo mi ha reso felice perche vuol dire che c'è speranzaSorride in fondo PI è una bella testata con molti lettori quindi è il giusto posto per chiedere aiuto in debug e test.
    Ma proprio per questa premessa mi sono detto...ma forse è troppo acerbo perchè per ora non risponde alle seguenti domande...e di qui le domande che ho postato nell'intervento precedente.
    Mi ricollego al tuo messaggio e aggiungo che è una rarità vedere gruppi coesi italiani che sviluppano per progetti open source di respiro internazionale.
    Tutto ciò è molto belloSorride
  • Per prima cosa una domanda: funziona su darwin (non ho detto Mac OS X)? Mi offro volontario come tester su darwin!

    Poi una IMHO: forse non ci è accorti che negli ultimi tempi si parla praticamente solo più di Ubuntu. Ubuntu qui, Ubuntu là. I newbie appena sanno la differenza tra Ubuntu e Linux e moltissimi ignorano completamente l'esistenza delle altre distribuzioni, figuriamoci quando vengono fuori discorsi tipo GNU\Linux non solo Linux (gnu? e che centra Piero Angela? Con la lingua fuori)

    Ma il problema è che molti utenti decisamente più scafati non ricordano che tutto è partito secondo una bellissima logica a bazar dove ognuno prendeva, modificava, forkava, faceva, apriva il sorgente ecc ecc.
    Quindi perché castrare un nuovo progetto? Cosa fa di male? Toglie le forze? Le forze a cosa? A Ubuntu? A Red Hat? A Microsoft!?!??!?!?!

    Una bella lettura a http://it.wikipedia.org/wiki/La_Cattedrale_e_il_Ba... non fa mai male ed evviva i nuovi progetti.

    Per altro, vedo che nessuno a spezzato una lancia per pkgsrc: http://www.netbsd.org/docs/software/packages.html e chi è NetBSD il figlio della serva? Con la lingua fuori

    E per finire questo inutile (ma divertente post):
    - emerge deriva dai ports di FreeBSD
    - Slackware deriva da BSD (almeno come struttura di init)
    - Fink è legato a doppio filo con Aqua: niente Mac OS X, niente Fink Triste
    non+autenticato
  • Eccellente. Ha riscoperto Fink/DarwinPorts/MacPorts e l'ha fatto per tutte le distribuzioni.

    Qualcuno di voi ha mai usato uno dei sistemi sopra citati? E' vero, funzionano. A parte qualche bachetto qua e là. Poi però viene resa disponibile una nuova versione di GCC; te gli dici di fare l'update, esci di casa per andare al lavoro, e quando torni FORSE ha finito di ricompilare le dipendenze.

    Usare le sorgenti ha dei vantaggi in termini di flessibilità, ma è devastante dal punto di vista prestazionale. Ben venga l'uso dei pacchetti binari precompilati per specifica piattaforma.
    non+autenticato
  • lol ha riscoperto ? O_o certo che secondo me non sapete leggere l'articolo.. nemmeno con gli occhi... cmq sia, compilare aiuta in termini di prestazioni, poiché il programma risulterà moooolto più veloce di un precompilato...
    non+autenticato
  • Beh, molto più veloce... dipende.
    Te lo dico da utente gentoo che ha configurato le sue cflags scegliendosele una ad una, studiando limiti e peculiarità del processore, prima di seglierle.
    Rispetto ad una distribuzione precompilata, gentoo guadagna circa un 10% (medio) in prestazioni, disabilitando il debug, utilizzando -O3 invece che -O2 o -Os, e configurando le USE flag in modo da non appesantire il sistema con parti o librerie inutili all'uso che se ne andrà a fare.

    Ottimizzando le CFLAGS, io personalmente, ma la situazione varia da PC a PC (quantità di cache L1, L2 e eventualmente L3, pipeline, FSB e tante altre cose, influiscono tutte), ho guadagnato un ulteriore 15% (sempre medio pesato fra più applicazioni di tipo diverso), però ho dovuto lavorarci parecchio.

    Più in generale, se non si fa un particolare lavoro di ottimizzazione (e non tutti i software lo permettono, ad esempio OpenOffice non c'è verso di compilarlo se non con un -O2 e tutti i CFLAG ulteriori disabilitati), il guadagno in termini di prestazioni, rispetto ad un binario precompilato per una qualsiasi distribuzione, è davvero trascurabile, soprattutto considerando che quasi tutte le distribuzione hanno versioni i386 (con pacchetti i586 e i686 la dove necessario), x86_64 e ia64.

    Insomma ci si potrebbe guadagnare qualcosina come prestazioni, ma non abbastanza da giustificare il tempo speso a compilare, infatti io gentoo la uso soprattutto come piattaforma di "apprendimento", poi normalmente uso SuSE o RedHat.
    non+autenticato
  • buffo l'Anonimo che bacchetta .. lui crede che il gioco sia partito da Fink. Il gioco e' partito dai ports di bsd, che esistono da un milione di anni prima di Fink e del suo sfavillante Mac
    non+autenticato
  • [OT]
    - Scritto da: Pino La Lavatrice
    > poi normalmente uso SuSE o
    > RedHat.

    RedHat e Suse.
    Detto tutto no? Infatti su Red Hat per compilare un kernel devi usare il suo folle sistema di compilazione a partire dai sorgenti pacchettizzati RPM e in seguito andare a usare una struttura di directory assurda.
    Su slackware un link simobolico chiamato /usr/src/linux

    E prima che mi si dica nulla: sono sistemista di sistemi di calcolo distributi e di sistemi di virtualizzazione in hardware. Ho litigato con SuSE ai tempi di Xen 3.0.2 (quando lo si doveva compilare da mercurial) e con iSCSI su Centos 5 e Scientific Linux.

    Compilazione è sicuramente ottimizzazione, ma è necessario usare la testa: avanti avanti avanti ok per fortuna ancora non funziona!
    [/OT]

    Sono d'accordo sulla questione tempi: anche io uso gentoo (su un server) e pensare di compilare KDE su una macchina (magari non troppo recente) è la morte.
    Però quando ci si trova per esempio su solaris/darwin/netbsd/ilsistemapiùstranochevipossiateimmaginare certi aiuti sono una manna dal cielo.
    non+autenticato
  • però c'è molta più flessibilità..
    non+autenticato
  • > Usare le sorgenti ha dei vantaggi in termini di
    > flessibilità, ma è devastante dal punto di vista
    > prestazionale. Ben venga l'uso dei pacchetti
    > binari precompilati per specifica
    > piattaforma.

    scusami omonimo anonimo, questa me la potresti spiegare?

    se configuri bene il compilatore, generalmente un compilato è più performante di un binario scaricato A bocca storta
  • Mi sento in imbarazzo per te a leggere una simile accozzaglia di parole (si noti che non ho parlato di idee ma solo di parole)
    Io sono uno delle tante persone che non usano assolutamente windows, ma riconosco che in alcune occasioni win sia molto comodo.
    In qualunque caso vorrei solo sottolineare come spesso nel mondo del lavoro (e non solo) le interfacce grafiche sono inutili e scrivere usando delle shell è la soluzione più veloce e flessibile; chissà perchè MS con il nuovo Win Server ha esteso la Powershell...
    Visto il tuo commento è evidente che non hai mai installato un pacchetto usando un qualsiasi Package manager perchè sapresti che il terminale puoi anche non vederlo.
    E' chiaro che non hai neppure capito a cosa serve questo progetto italiano, progetto che spero possa aiutare a eliminare il problema della pacchettizzazione frammentaria delle varie distro.
    non+autenticato
  • Augh,

    è raro incontrare notizie positive, ed è bello poterlo sottolineare.

    Mi auguro di tutto cuore che questo progetto vada dove dice di voler andare: sarebbe veramente OTTIMO!!!

    Ho parlato

    Nilok
    Nilok
    1925
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 12 discussioni)