The NeXTStep: Developer time! - La compilazione da sorgenti e il package management

Agognato da tempo immemore, sfuggito di poco più e più volte nelle aste online, finalmente recupero un compact disc di NeXTStep Developer 3.3 (from U.S. of America, Ou iea!).
Infilo il CD nel caddy, infilo il caddy nel lettore, Workpace Manager mi mostra l'icona del volume montato. Mi aggiro per le directory del CD alla ricerca dei pacchetti da installare: NextCD/packages. Doppio click sui file e con i privilegi di root parte Installer.app.



Installer.app è l'utility presente in NeXTStep per aiutarci nella gestione del software da installare o da rimuovere: l'utilizzo è immediato: l'installazione dei pacchetti può essere eseguita da qualsiasi directory del sistema. Una volta che il pacchetto è stato installato verrà conservato nel database /NextLibrary/Receipts in forma di informazioni quali ad esempio lo status (installato o meno), i percorsi dei file e così via. Il sistema di gestione dei pacchetti è quello classico di Unix, e di distribuzioni come Slackware.


A questo punto ci ritroviamo con un ambiente di sviluppo bello e pronto. Prima di procedere verso il laboratorio con una camminata alla Frankenstein, un paio di migliorie al nostro sistema:
1) installazione della patch a NeXTStep Developer: la troviamo sul sito Apple - nostalgico Jobs: http://docs.info.apple.com/article.html?artnum=70124
2) installazione del GNU C Compiler: la versione più recente che sono riuscito a trovare per NeXTStep è la 2.95.3, che mi ha aiutato nella compilazione di grep (con una versione precedente il make non andava a buon fine): http://www.savarese.org/patches/gcc.html

Fa caldo. I vapori dell'acqua calda dentro la vasca creano una nebbia, mi soffoca. Inietto il pacchetto di grep via ftp, quei pochi secondi sembrano un'eternità. Mi asciugo il sudore. Con la sinistra lo tengo fermo, con la destra prendo gunzip e lo decomprimo, poi tar xf, lo scompatto, e mi ritrovo a guardargli dentro il petto: una zaffata di zolfo mi arriva alle narici, gas di putrefazione. Ho un conato. Guardo il Changelog, sono sorgenti del 1996; nessuno ne sentirà la mancanza!
Procedo, è il momento del configure per la mia creatura. Lo costringo ad un --prefix ben preciso, così da aiutarmi nella fase finale dell'opera. Tutto procede secondo i piani... La tempesta è arrivata: una luce rischiara le nuvole di vapore nella stanza, poi un boato al quale le finestre rispondono: non ci resta che aspettare. E finalmente eccolo: la corrente scorre per i circuiti CISC, si immagazzina nelle bobine, devo solo abbassare la leva: make !
La carne brucia, ne sento l'odore. Mi siedo, sono soddisfatto e stanco, posso permettermi qualche minuto di riposo. I succubi approfittano di me.
Apro gli occhi, la tempesta è finita. Nebbia e silenzio creano un'atmosfera surreale. La mia creatura? Mi avvicino, e la guardo...
Sì può fare!

Procediamo quindi alla creazione del pacchetto. Il make install copierà i binari nella directory da me suggerita al configure --prefix= che per questioni stilistiche e pratiche, sarà: /tmp/pkg.
A metà degli anni '90, quando i Makefile non erano creati da tool automagici come Automake, le strade per consigliare un percorso per l'installazione erano due: quella usata qui, quando esiste lo script di configure, oppure andare a modificare a mano il Makefile. Creata la radice del pacchetto, ora concentriamoci sul file .info necessario a Installer.app per la corretta gestione del pacchetto.
Il nome del file in questione dovrà corrispondere al nome del pacchetto, in questo caso, quindi, avremo un grep.info e il successivo e finale grep.pkg.
grep.info che andremo a creare in /tmp/, è suddiviso in otto sezioni:

Title Il nome del pacchetto. Nella prima immagine è "grep - GNU grep"
Version La versione del software
Description La descrizione del programma
DefaultLocation Il prefisso d'installazione del pacchetto
Diskname Il nome della directory del pacchetto, nel nostro esempio "grep.pkg"
Relocatable Una variabile, i cui valori possono essere YES o NO, che permette all'utente finale di sovrascrivere la DefaultLocation
Application YES o NO, indica se il contenuto del pacchetto è un'applicazione o meno
DeleteWarning seguito dal messaggio di avvertimento, verrà mostrato quando si vorrà cancellare il pacchetto.

E ora viene la parte più facile. Installer.app si porta dietro un'utility scritta appositamente per la creazione di pacchetti: package, la cui sintassi di base si presenta così:
package directoryradicedelpacchetto fileinfo -d directorydovesalvareilpacchetto
che, per il nostro esempio, diventerà:
package /tmp/pkg/ /tmp/grep.info -d /me/

Generating Installer package /me/grep.pkg ...
    creating package archive ... done.
    copying grep.info ... done.
    generating bom file ... done.
    generating sizes file ... done.
... finished generating /me/grep.pkg.

Diventiamo root, doppio click sul pacchetto e Installer.app farà il resto.

Fonte: http://www.bangmoney.org/nextstep/packages_1.html

Su Slackware, Gnome, e la pigrizia: la via della sperimentazione

Da pochi giorni, Volkerding ha messo mani al changelog di Slackware -current, e io da bravo bleding edger quale sono ho masturbato la mia vetusta installazione (non ripulivo l'hard disk da Slackware 9.1) aggiornando al solito, vecchio e sensuale modo, come piace alla mia donna preferita: con le mani.
Scarico i pacchetti, è una domenica sera uggiosa, violentata dai pensieri di quell'idiota che è riuscito a farmi incazzare il pomeriggio prima... Intanto guardo la tv, spenta, visto che non trasmettono un emerito cazzo da mesi nell'etere.
Torno dalla scorribanda televisiva, è tardi, il giorno dopo avrò il turno mattutino (bene, tempo per le bisite il pomeriggio!): sono indeciso se dare l'upgradepkg ora o domani, ripetendomi l'UPGRADE.TXT in testa più volte:

repeat
begin
0) init 1 ;
1) upgradepkg glibc-solibs-* ;
2) upgradepkg pkgtools[TAB] (magie di bash_completion) ;
stachezza:=stanchezza+1;
end;
until stanchezza=11;

Me, disgraziato:

Upgrade your glibc shared libraries.  This is important, or things
might go haywire during the first part of the upgrade.

root@lounge# upgradepkg *.tgz
[CTRL+C] [CTRL+C] [CTRL+C]

root@lounge# ls
Segmentation fault
root@lounge#

A nulla sono serviti i miei tentativi di "bootare" da cd, usare chroot: le cose non si fanno a caso, la teoria non basta.

"It's time to back-up!"
Gigabytes di perversioni salvate. E con loro tutta la mia vecchia /home/michele.
La fedeltà alla mia regina, mi ha portato all'acquisto del cofanetto di sei cd di Slackware Linux 11.0: li ho usati.
La fedeltà di cui sopra mi aveva anche costretto, non senza sommo piacere, a tenere alla larga dal mio sistema tool automagici che tanto ricordavano quelli propagandati dal lato oscuro della forza(Debian, NdS.). Tuttavia, questioni di tempo, e soprattutto di merging nel tree ufficiale della distribuzione, mi hanno spinto a provarli.

Slackpkg, funziona. Confronta il changelog di Slackware -current (o delle altre versioni, previa configurazione, a mano) con i pacchetti installati, e propone aggiornamenti, e installazione di nuovo software. Dall'interfaccia in ncurses, è possibile selezionare pacchetto per pacchetto in base alle proprie esigenze di aggiornamento. Quello che trovo di estremo interesse in questa dis-utility è il comando: slackpkg clean-system, che elimina dal sistema i pacchetti non più presenti in Slackware. Penso non ne farò a meno.

Portpkg, funziona anche lui. Non è altro che un sistema di ports per Slackware. La cosa interessante (un po' come per i ports di diabolica memoria (BSD, NdS.) o il portage di Gentoo (ma guarda un po')) è che l'amministratore di sistema può mettere mano a tutti gli Slackbuild a disposizione, e crearsene di nuovi. Un buon metodo se volete usare sempre l'ultima versione dei vostri programmi preferiti, senza dare ad ogni release gli stessi comandi per la compilazione. Con lui ho ridotti i tempi di una compilazione manuale di Gnome, utile.

Con il sistema installato e pronto all'uso, mi preparo a rimettere in piedi una brutta copia del sistema che ero riuscito a costruire in tre anni di isolazionismo dalle tentazioni di un desktop environment: il mio WindowMaker riusciva a conciliare orpelli moderni con il suo dannato fascino vintage. Per fare ciò, mi appoggiavo alle librerie di Gnome, tra le innocue Gtk+ e le decine di viziose dipendenze che ogni programma con la "G" davanti, si portava dietro. All'inizio usando ancora l'installazione di Gnome 2.6 di un'imprecisata versione di Slackware, poi aggiornando a mano (portpkg invero mi ha aiutato con qualche automatismo) pacchetto per pacchetto a Gnome 2.16.
La via scelta in questi giorni è stata diversa: automatismi o binari. Fallita la prima strada (http://www.mkanet.de/data/faq/faq.html), troppo tedesca, al via la prova delle distribuzioni Gnome per Slackware:
- Freerock Gnome (GSB - Gnome SlackBuilds): ricordo di aver prelevato da loro pacchetti binari di pregevole fattura, purtroppo però la versione attuale stabile è la 2.14.3;
- Dropline Gnome: manie di protagonismo che vanno ad intaccare troppe cose della mia donna: è più sexy quando è pulita piuttosto che truccata;
- GWare: la scelta che ho fatto: gli unici pacchetti che ha sovrascritto sono stati le GTK+ (con atk, pango, glib2, eccetera) e DBus. Stop.
Nonostante l'ottimo prodotto, ritrovare un sistema totalmente usabile con sottofondo Gnome, non è affatto immediato. Manca di linee guida basilari per la creazioni di applicazioni: chiunque può scegliere un linguaggio, scriverci dei bindings alle GTK+ e crearsi le proprie applicazioni: così, oltre a combattere con le dipendenze gnomiche, avrai anche quelle per Python, Perl, con i fastidi di un linguaggio interpretato. Senza contare la necessità di vivere in Slackware -current.

Ora basta, vado a prepararmi. Esco a cena con Qt. Probabilmente sarà solo una serata in compagnia di una bella donna, ma tanto basterà per farmi capire se tornare a casa per restare o per preparare le valigie.