Come migrare distribuzioni gnu/linux su powerpc

In Novembre del 2012 abbiamo anticipato la produzione di un sistema di sviluppo economico e potente con processore powerpc, prodotto dalla Servergy
che essenzialmente si occupa di server powerpc per data-center.

In questi mesi Servergy oltre occuparsi del suo core business, ovvero i data center, sta preparando assieme anche con il mondo Amiga ( fedele da sempre all'architettura Powerpc) e Freescale, il disegno e la produzione di pcubed, l'annunciato sistema di sviluppo.



Anche io, noto rompiballe che contatta direttamente i produttori, anche quelli grandi, ho spinto per una versione "figa" di pcubed , non ho la presunzione di essere influente, ma delle volte non fa male stimolare...

In questi mesi da Marzo 2013 Servergy ha capitanato i meetup degli utenti che ha battezzato Power Linux ( powerpc) , per accompagnare utenti e sviluppatori gnu/linux a portare applicazioni gnu/linux su architettura powerpc; ho seguito personalmente i meetup da Aprile.

Servergy ha fornito anche degli ambienti remoti di test basati su piattaforma power, chiamati RPLE, come già illustrato in questo blog trovate il post "Migrare ad architettura powerpc: come fare?" dove aggiorno sul meetup di Maggio e il post "Powerpc back to the future!" dove essenzialmente aggiorno del meetup di Aprile.


Con questo post vi aggiorno del meetup di Giugno, e proprio perché non è stato possibile seguirlo via webinar, per lo meno è stata registrato un breve video dell'intervento di Ben Collins, che è il responsabile tecnico di Servergy, nonché noto esperto di gnu/linux su architettura powerpc, che segue da anni il team di volontari di ubuntu per powerpc ( tra cui ci sono anche io).

Vi avviso, armatevi di pazienza, perché il video oltre ad essere in inglese ha un audio non eccezionale,aiutatevi con la mia traduzione, molto approssimativa delle slide o la versione originale in inglese delle stesse.

Qualche comprensione del processo di creazione di una distribuzione ce lo ho, dato che ho lavorato tra il 2002 ed il 2003 per Made in Linux,una distribuzione linux italiana derivata da Red Hat.

Come illustrano le slide bisogna prima decidere da quale base di partenza fare la migrazione di una distribuzione gnu/linux nata non per powerpc verso l'architettura powerpc e decidere sino a che livello di completezza portare a termine la migrazione.
Ad esempio bisogna chiedersi:
Migrare solo i pacchetti base per fare funzionare gnu/linux?
Oppure  solo tutti i pacchetti a corredo del cd di installazione?
Sicuramente conviene partire con l'opera mettendo in conto una certa proporzione di fallimento dell'impresa.

Primo passo bisogna mettere in piedi il sistema per compilare i pacchetti per architettura powerpc , a tale scopo si potrebbe mettere in piedi un sistema in chroot, oppure un sistema completo.
Serve avere un ambiente il può possibile "incontaminato" ed avere in questo ambiente l'essenziale per compilare e produrre pacchetti.

Ho contattato direttamente Ben Collins, che mi ha prontamente risposto, per chiedergli un aiuto per la mia comprensione su di un parte del suo parlato e delle slide.

Quindi si può partire in questa impresa di migrazione verso powerpc, seguendo la strada che hanno fatto alcune distribuzioni derivate da altre , prendiamo l'esempio di Red Hat 5 e CentOS 4.2   , infatti se dovessimo derivare RHEL 5 da Centos 4.2, avremmo distribuzioni simili ma non identiche, dato che Centos 4.2 avrebbe dei pacchetti più vecchi, di quelli che in effetti dovranno essere compilati per RHEL 5.

Si parte dai pacchetti essenziali per compilare gli altri e  che vengono usati quelli della distribuzione da derivare (gcc, binutils, glibc, auto*, gettext)
- Per tutte le librerie che non sono quelle per compilare i paccheti si cerca di ricompilare tutte di modo da svincolarsi il più possibile dalla vecchia distro. Dato che partendo da una distro più vecchia per produrne una nuova le versioni delle librerie che dovremo compilare sono più recenti , c'è una bassa aspettativa che abbiano successo le compilazioni dei pacchetti.

- Le librerie andranno in conflitto durante  lo  stage 1, ovvero la compilazione di cui staimo parando, infatti per risolvere questi conflitti sarà necessario via via ricompilare i pacchetti delle librerie di base, ovvero quelli previsti nello Stage 2, quando si arriva a ricompilare tutti i pacchetti della distro.

Nel caso invece di OpenSuse e Suse abbiamo praticamente la stessa distribuzione , (derivazione da OpenSuse 11.2 di Suse 11) ovvero si parte sempre dal nucleo di pacchetti per compilare gli altri ( ggc, binutils, glibc, auto*, gettext) , si usano tute le librerie di base della distro di partenza, ricompilando solo i pacchetti non librerie , ovviamente in questo caso l'aspettativa di successo è molto alta, non serve lo stage 2.

L'intervento manuale
Le catene di dipendenza tra le varie librerie implicano cicli di compilazione lineari lunghi. Le catene possono avere molti rami. 
Questo aggroviglio di library per essere smatassato potrebbe essere aiutato da strumenti di analisi.

Arrivare alla conclusione delle compilazioni
- Ambiente di sviluppo basato sui propri pacchetti ricompilati
- Un ultima ricompilazione di tutto l'ambiente
- Nessun pacchetto dalla base originale
- Check di salute 


Se ascoltando il video trovate errori ed imperfezioni nella mia comprensione (sicuramente ce ne sono diversi), vi prego di suggerirmi le migliorie e modifiche a questo post.

grazie