# Produrre pacchetti binari per più di un pc

## Onip

Il corso di Sistemi Operativi B mi da, finalmente, la scusa per mettere linux anche sul portatile.

Per adesso, siccome mi serviva un'installazione veloce, ho messo su una Ubuntu, ma, no so, non mi convince molto...

L'idea, quindi, era quella di mettere gentoo. Quello che vorrei fare è compilare ed installare sul fisso e, allo stesso tempo, fare i package per il notebook (Feature="buildpackage") in modo da risparmiare in tempo di manutenzione.

Le due installazioni verrebbero più o meno clonate (userei penso gli stessi pacchetti...)

Il fisso è un Pentium4, mentre sul note ho un Centrino.

La domanda, quindi, è: come setto le CFLAGS?

adesso ho queste

```
CFLAGS="-Os -march=pentium4 -fomit-frame-pointer -pipe"
```

Pensavo di passare ad un -march=i686, è meglio qualcosa di più spinto, anche sotto il piano delle performance e dello sfruttare le varie estensioni (mmx, sse etc etc...)

Inoltre, devo porre attenzione a qualcos'altro in particolare?

Ah, ultima cosa, per il sync come mi comporto? se li synco nello stesso momento non dovrei avere problemi, immagino, o mi conviene settare un rsync mirror privato sul fisso?

Byez & Gracias

----------

## !equilibrium

 *Onip wrote:*   

> Il fisso ï¿½ un Pentium4, mentre sul note ho un Centrino.
> 
> La domanda, quindi, ï¿½: come setto le CFLAGS?
> 
> adesso ho queste
> ...

 

```
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"
```

credo che sia sufficiente. i686 include MMX e SSE di default, quindi non devi specificare esplicitamente le CFLAGS (sempre che qualche d'un altro non mi contraddica).

 *Onip wrote:*   

> Ah, ultima cosa, per il sync come mi comporto? se li synco nello stesso momento non dovrei avere problemi, immagino, o mi conviene settare un rsync mirror privato sul fisso?

 

non ho capito cosa intendi

----------

## Ic3M4n

io ho tutto i686. la cosa migliore è clonare i file di conf di portage, io di solito faccio un link ad /etc/make.conf in /etc/portage/make.conf e sposto tutta la dir. in questo modo hai le stesse use flag e gli stessi pacchetti in testing. 

altra cosa che puoi/devi fare è impostare uno dei due pc come master per l'rsync, in modo da non uscire due volte sul web per il sync, inoltre la stessa cosa puoi farla per scaricarti i pacchetti, io preferisco avere comunque ed in ogni caso i sorgenti sul portatile. a volte tornano utili.   :Wink: 

quindi abiliti in /etc/rsync.conf la dir che vuoi condividere, di solito basta decommentare quella e mettere l'indirizzo ip del pc nel make.conf sotto a SYNC

poi per condividere i sorgenti ed i binari puoi utilizzare webfsd, una sola istanza in /usr/portage e configurare

GENTOO_MIRRORS su TUO_IP e PORTAGE_BINHOST su TUO_IP/packages/All

quando aggiorni esegui un emerge -uDNgk world, dall'uno e dall'altro. 

io una volta a settimana faccio anche un fetch dei sorgenti con emerge -ef world.

----------

## Peach

N soluzioni direi!

le prime che mi vengono in mente:

distcc

l'idea di fare tutto i686 e' comoda se nel fisso hai GIA' i686.

pacchettizzare tutto ed esportare la dir di protage (quindi senza nemmeno averla fisicamente sul laptop) via NFS.

al momento non mi viene in mente altro... penso alla cena  :Razz: 

----------

## djinnZ

Una volta usavo i686 ma avevo sia intel che amd, da un p2 originale a un sempron. Contrariamente a quanto indicato nell'apposita guida di cui non ricordo il link ho athlon-xp (alla fine ho provato e funziona) funzionante anche su duron.

Fai un cat /proc/cpuinfo e vedi se sono supportate sse2 etc. e scegli il minimo comun denominatore.

A naso anche p3 dovrebbe andare.

----------

## Ic3M4n

io ricordo che all'inizio con gcc 3.3 sul portatile compilavo per pentium4 perchè non esisteva ancora pentiumM. probabilmente funziona ancora ma non ne sono sicuro. nel caso ti eviti una ricompilata.

----------

## Alakhai

-march=pentium3 credo sia la più spinta e la più compatibile tra centrino e pentium4

e non dimenticarti di mettere anche -fomit-frame-pointer -pipe -O2 !

e volendo -funroll-loops ma potrebbe non essere il massimo per il portatile, visto che fa dei binari più grandi

----------

## Ic3M4n

ho trovato la discussione riguardante le cflags per centrino che avevo utilizzato io ai tempi per impostare le mie.

https://forums.gentoo.org/viewtopic-t-263995-highlight-pentiumm.html

----------

## djinnZ

 *Onip wrote:*   

> Ah, ultima cosa, per il sync come mi comporto? se li synco nello stesso momento non dovrei avere problemi, immagino, o mi conviene settare un rsync mirror privato sul fisso?

 

Dipende da quel che fai. I metodi pratici sono due, se non pensi di trovarti ad installare pacchetti all'occorrenza usa lo share nfs come ti ha detto peach e ti eviti complicazioni, se vuo una soluzione più versatile installati un mirros rsync sul fisso ed esporti via nfs distfiles e package (è inutile sprecare spazio sul portatile).

----------

## Onip

grazie a tutti per i consigli!

Do tempo ad Ubuntu di convincermi fino a fine settimana (anche perchè prima non ho tempo...) poi vedrò di passare alla "trasfusione" di gentoo. Per adesso posto i cpuinfo

 *Pentium4 wrote:*   

> 
> 
> onip @ Hal9000 ~ $ cat /proc/cpuinfo 
> 
> processor       : 0
> ...

 

 *Centrino wrote:*   

> 
> 
> onip @ Hal9000 ~ $ cat /proc/cpuinfo
> 
> processor       : 0
> ...

 

Effettivamente allo share via nfs non avevo proprio pensato...

L'unica cosa che veramente mi frena è il dover ri-emergere il mondo, con tutto il tempo che ci va dietro.

----------

## djinnZ

Se non vuoi clonare per risparmiare spazio puoi fare così:

Installa lo stage3 e copia make.conf sul portatile

sul P4

```
for i in `qpkg -nc -v -I` ; do if [ ! -f /usr/portage/packages/All/`echo $i | sed "s/^.*\///"`.tbz2 ]; then quickpkg =$i; fi; done
```

come descritto qui

esporti sempre via nfs portage/package e lo monti sul portatile

a questo punto dai un emerge -eK world e dovresti essere a posto. (bada che le varie conf saranno identiche)

Poi ti emergi i pacchetti che ti servono e dai un revdep-rebuild. Nel giro di un'oretta al massimo dovresti essere a posto.

La prova con ottimizzazione p4 la farei... se non va del tutto bene e vuoi proprio essere sicuro configura distcc prima, riemergi con le nuove flag il gcc sul portatile e poi lanci un emerge -eB world. (ricordati di aggiungere -j3)

Quando hai finito ti riporti i pacchetti al portatile sempre con -eK.

Al tuo posto inizierei a lavorare con P4 e poi un poco per volta farei la conversione, tanto per sicurezza. Bada -K, non -k.

Se cambi cflag inizia da glib e glibc.

----------

## Ic3M4n

la -K è molto fastidiosa. se non hai tutti i pacchetti di tutte le dipendenze emerge esce senza fare nulla, logicamente.

solitamente preferisco utilizzare la -k. in questo modo se i pacchetti smascherati sono gli stessi prende i pacchetti disponibili e quelli che non ha li compila. Non ho mai capito come mai alcuni pacchetti non li ho mai. bah...   :Rolling Eyes: 

----------

## Cazzantonio

Queste vanno bene per tutto dal pentium3 in su

```
CFLAGS="-O2 -march=i686 -mmmx -msse -msse2 -pipe -fomit-frame-pointer"
```

Io è una vita che compilo in questo modo e ti assicuro che non noto nessun calo prestazionale   :Wink: 

----------

## djinnZ

 *Ic3M4n wrote:*   

> solitamente preferisco utilizzare la -k. in questo modo se i pacchetti smascherati sono gli stessi prende i pacchetti disponibili e quelli che non ha li compila. Non ho mai capito come mai alcuni pacchetti non li ho mai. bah...  

 

Se stai clonando il sistema (cosa che ho appena fatto, per questo lo dico) a partire da uno stage3 applicando tutte le useflag ti verranno fuori un bel pò di dipendenze circolari e problemi di compilazione (in questo gentoo si sta rivelando un pò inconsistente). In più ci sono alcuni pacchetti (non me li sono segnati ma sono le solite librerie di wrapper, automake e java/xml) che a quanto pare sono inseriti nelle dipendenze ma non sono necessari alla corretta compilazione.

Prova a lanciare un emerge -eDNupv world e vedrai che ti sicuro ti mancano una o due "sciocchezzuole".

Agendo con -K world e --resume --skipfirst ed un revdep-rebuild alla fine riesci a tirare su un sistema funzionante in molto meno tempo.

Aggiungi poi che alcune dipendenze cambiano installando vari pacchetti, gli slot che non vengono aggiornati a meno che non te li vai a trovare e li emergi con -1 =... e ci sono le ovvie confusioni del --depclean.

In realtà sarebbe buona norma creare i pacchetti binari passo passo, e non cancellarli subito, spazio su disco permettendo, ovviamente.

A parte il fatto che per evitare guai sarebbe buona norma usare sempre il -b quando si aggiornano elementi critici come glib, libc, baseutil, portage, phython, init et simila.

----------

## Ic3M4n

Un'altra cosa che bisogna tenere conto è che alcuni pacchetti sono da installare a mano con --oneshot. in pratica sono tutti i pacchetti che sono presenti in RDEPEND e non in DEPEND e sono alla fine i pacchetti necessari alla sola compilazione del pacchetto.

----------

## Onip

 *Cazzantonio wrote:*   

> Queste vanno bene per tutto dal pentium3 in su
> 
> ```
> CFLAGS="-O2 -march=i686 -mmmx -msse -msse2 -pipe -fomit-frame-pointer"
> ```
> ...

 

Perfetto, grazie.

 *Ic3M4n wrote:*   

> Un'altra cosa che bisogna tenere conto è che alcuni pacchetti sono da installare a mano con --oneshot. in pratica sono tutti i pacchetti che sono presenti in RDEPEND e non in DEPEND e sono alla fine i pacchetti necessari alla sola compilazione del pacchetto.

 

Se sono necessari alla sola compilazione allora ne posso fare anche a meno, immagino. L'idea, appunto, è quella di compilare solo su di un pc e usare il "compilato" per 2. O mi sbaglio?

----------

## djinnZ

 *Onip wrote:*   

> Se sono necessari alla sola compilazione allora ne posso fare anche a meno, immagino. L'idea, appunto, è quella di compilare solo su di un pc e usare il "compilato" per 2. O mi sbaglio?

 

Si, però credo che l'intenzione era metterti in guardia e non andare in paranoia se qualche pacchetto più "barocco" va in errore durante l'aggiornamento o se lo devi installare "all'impronta" solo sul portatile. Se poi sei sicuro che non ti capiterà e aggiornerai sempre solo sul server per poi portarlo sul portatile vai tranquillo.

Per esempio c'è una libreria xml/html di java (non mi ricordo come si chiama) non ti serve assolutamente a niente durante il normale funzionamento del sistema e ne puoi fare a meno ma se hai USE="doc java xml" (e non ricordo quale altra) ci sono una mezza dozzina di pacchetti che danno errore in fase di compilazione.

Ovviamente sapendolo vai direttamente a capire qual è senza chiederti cosa hai sbagliato e pensare di farti del male ricompilando mezzo mondo.

----------

## Ic3M4n

@djinnZ: mi hai capito in pieno   :Wink: 

----------

## Onip

ah, ok. Fino a lì c'ero anche io   :Wink:  . L'ebuild mal scritto è sempre dietro l'angolo... Avevo capito fosse un suggerimento un po' più "categorico"

----------

## djinnZ

in realtà non è proprio un errore, è solo molto mal documentato, in fin dei conti cosa ti frega di avere qualche strana libreria che serve solo a tradurre le doclet java in xml o pdf quando generi il pacchetto se non pensi mai di compilarlo su quel computer?

Se non è l'ora tarda e la fame che mi fa sragionare dovrebbe essere una reminiscenza delle grp.

----------

