# [SYSTEM]Nuove glibc

## MonsterMord

A proposito delle nuove glibc-2.3.5 ho le use flags messe cosi'

"+nls -nptl -nptlonly"

Ha senso abilitare la nptl e/o la nptlonly?

Che vantaggio ne otterrei?

Grazie.

----------

## SilverXXX

Si ha un grosso vantaggio in java, e in alcuni applicazioni che fanno grosso uso di thread (es. un dbms con accessi multipli) principalmente. Cmq dovrebbe essere meglio in generale. Se metti nptl, ti compila sia la nuova che la vecchia libreria per compatibilità, con nptlonly solo la nuova. Ormai cmq non ci dovrebbero essere problemi anche con nptlonly.

----------

## Kernel78

 *MonsterMord wrote:*   

> A proposito delle nuove glibc-2.3.5 ho le use flags messe cosi'
> 
> "+nls -nptl -nptlonly"

 

di sicuro devi togliere il + davanti alle USE che vuoi abilitare  :Wink: 

altrimenti ottieni errori 

```
USE flags should not start with a '+': +nls
```

----------

## CRV§ADER//KY

 *SilverXXX wrote:*   

> Ormai cmq non ci dovrebbero essere problemi anche con nptlonly.

 

Ho sempre saputo che le applicazioni closed source non funzionano con nptlonly...

----------

## SilverXXX

Non so, a me pare che applicazioni recenti non diano problemi (al momento però non ho nptlonly), ma per certezza si dovrebbero fare un pò di prove.

----------

## Kernel78

 *CRV§ADER//KY wrote:*   

>  *SilverXXX wrote:*   Ormai cmq non ci dovrebbero essere problemi anche con nptlonly. 
> 
> Ho sempre saputo che le applicazioni closed source non funzionano con nptlonly...

 

Non saprei cosa dire, è una vita che non uso più sw closed  :Cool:  quindi uso tranquillamente nptlonly

----------

## .:chrome:.

NPTL è l'acronimo di Native POSIX Threading Library.

in sostanza quando compili con NPTL passi da un modello a processi ad uno a thread.

la differenza sta nel modo in cui il sistema operativo gestisce lo scheduling. i programmi sono divisi in processi (per intenderci... ogni processo ha un PID, in UNIX) e i processi hanno una gerarchia di sottoprocessi.

per passare da un processo all'altro (interazione fra programmi, chiamata di librerie, o semplice prelazione dello scheduler) si deve generare unìinterruzione, passare da user-mode a kernel-mode, selezionare il nuovo processo ed attivarlo (questo si chiama context-switch).

se hai un modello a thread, hai sempre i processi, ma non i sottoprocessi. al posto di questi trovi i thread, e quelli sono gestiti direttamente dal processo supervisore. per passare dall'uno all'altro non è necessario alcun context-switch, perché resta tutto all'interno del processo supervisore (i panni sporchi si lavano in casa).

questo da un discreto vantaggio di prestazioni.

nptl compila DUE VOLTE glibc, una volta con il tradizionale LinuxThreads e una volta con NPTL (se fai attenzione all'output di compilazione, all'inizio lo leggi), in modo da offrire ai programmi che lo supportano anche NPTL.

nptlonly compila UNA VOLTA glibc, solo con supporto POSIX Threads e senza LinuxThreads. a tua discrezione: il supporto ai LinuxThreads lo si potrebbe mantenere per compatibilità. il computer da cui sto scrivendo ora non ha mai visto nemmeno per sbaglio il supporto a LinuxThreads e non mi ha mai dato nessun tipo di noia... 

spero di essere riuscito a spiegarmi

----------

## Kernel78

 *k.gothmog wrote:*   

> il computer da cui sto scrivendo ora non ha mai visto nemmeno per sbaglio il supporto a LinuxThreads e non mi ha mai dato nessun tipo di noia...
> 
> 

 

il mio pc invece l'ha visto per sbaglio (avevo scritto ntplonly invece di nptlonly  :Embarassed:  )

 *Quote:*   

> 
> 
> spero di essere riuscito a spiegarmi

 

Si, in maniera molto chiara.

----------

## .:chrome:.

 *Kernel78 wrote:*   

>  *k.gothmog wrote:*   il computer da cui sto scrivendo ora non ha mai visto nemmeno per sbaglio il supporto a LinuxThreads e non mi ha mai dato nessun tipo di noia... 
> 
> il mio pc invece l'ha visto per sbaglio (avevo scritto ntplonly invece di nptlonly  )

 

secondo me è buona abitudine usare emerge -v

----------

## Kernel78

 *k.gothmog wrote:*   

> secondo me è buona abitudine usare emerge -v

 

Io la uso sempre (in genere anche con -a), tranne quando faccio emerge -f ma avevo dato per scontato di aver scritto tutte le use correttamente quindi non ho controllato più di tanto, me ne sono accorto quando ho letto l'avvertimento sulla compilazione doppia in quanto non era specificato nptlonly  :Rolling Eyes: 

----------

## .:chrome:.

ecco quell'avviso di cui parlavo:

```
 * Warning! Gentoo's GLIBC with NPTL enabled now behaves like the

 * glibc from almost every other distribution out there. This means

 * that glibc is compiled -twice-, once with linuxthreads and once

 * with nptl. The NPTL version is installed to lib/tls and is still

 * used by default. If you do not need nor want the linuxthreads

 * fallback, you can disable this behavior by adding nptlonly to

 * USE to save yourself some compile time.
```

----------

## CRV§ADER//KY

E' solo una mia impressione o con le nuove glibc il mio tempo di boot (da lilo ad XFCE, col login automatico) è calato da 2m30s a 2m10s?

----------

## MonsterMord

 *k.gothmog wrote:*   

> 
> 
> spero di essere riuscito a spiegarmi

 

Pure troppo  :Razz: 

Alla fine ho optato per "+nls +nptl +userlocales", gli aggiornamenti delle glibc non vengono rilasciati di frequente e compilare due volte non e' un problema. In piu' avere una retrocompatilbilta' non guasta (ho diversi vecchi giochi closed che temo possano dare problemi).

Se posso aggiungere una considerazione:

era ora che mettessero stabili le 2.3.5 invece che partire dalle 2.3.3 patcharle con un snapshot a caso del CVS e creare quell'obrobrio di 2.3.4-qualchedataacasochenonvabeneperniente (vedi bug #90825)

Mi sembra che gli sviluppatori gentoo prendano un po' troppo alla leggera le glibc, e' un componente _fondamentale_

Saluti.

----------

## Kernel78

 *MonsterMord wrote:*   

> Alla fine ho optato per "+nls +nptl +userlocales"

 

e hai sbagliato, se vuoi attivare una use basta il nome, non devi metter il + davanti  :Rolling Eyes: 

----------

## MonsterMord

 *Kernel78 wrote:*   

> e hai sbagliato, se vuoi attivare una use basta il nome, non devi metter il + davanti 

 

Ho messo il "+" solo nel post per specificare meglio le USE flag attive, come vuole la sintassi del portage

```

sys-libs/glibc-2.3.5  -build -debug -erandom -hardened (-multilib) +nls +nptl -nptlonly -pic (-selinux) +userlocales

```

----------

## Kernel78

 *MonsterMord wrote:*   

>  *Kernel78 wrote:*   e hai sbagliato, se vuoi attivare una use basta il nome, non devi metter il + davanti  
> 
> Ho messo il "+" solo nel post per specificare meglio le USE flag attive, come vuole la sintassi del portage
> 
> 

 

Pensavo l'avessi messo in make.conf (ho visto motli farlo e ignorare gli errori USE flags should not start with a '+': +<USE>)

----------

## horace

ho un problema nell'emerge glibc con il supporto nptl

```

In file included from ../nptl/sysdeps/unix/sysv/linux/i386/fork.c:31:

../nptl/sysdeps/unix/sysv/linux/fork.c: In function `__libc_fork':

../nptl/sysdeps/unix/sysv/linux/fork.c:203: error: can't find a register in class `BREG' while reloading `asm'

make[2]: *** [/var/tmp/portage/glibc-2.3.5/work/build-default-i686-pc-linux-gnu-nptl/posix/fork.o] Error 1

make[2]: *** Waiting for unfinished jobs....

make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5/posix'

make[1]: *** [posix/subdir_lib] Error 2

make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5'

make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.3.5 failed.

!!! Function toolchain-glibc_src_compile, Line 244, Exitcode 2

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.

```

ed ecco le mio info

```
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r11 i686)

=================================================================

System uname: 2.6.11-gentoo-r11 i686 Intel(R) Pentium(R) M processor 1500MHz

Gentoo Base System version 1.4.16

Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May  6 2005, 19:19:55)]

dev-lang/python:     2.3.5

sys-apps/sandbox:    [Not Present]

sys-devel/autoconf:  2.59-r6, 2.13

sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5

sys-devel/binutils:  2.15.92.0.2-r10

sys-devel/libtool:   1.5.16

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CFLAGS="-march=pentium3 -fomit-frame-pointer -pipe -O2 -mfpmath=sse -mmmx -msse -msse2 -fprefetch-loop-arrays -falign-functions=32 -fPIC "

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-march=pentium3 -fomit-frame-pointer -pipe -O2 -mfpmath=sse -mmmx -msse -msse2 -fprefetch-loop-arrays -falign-functions=32 -fPIC "

DISTDIR="/usr/portage/distfiles"

FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"

USE="x86 X a52 aac aalib accessibility acl acpi adns alsa apache2 arts atlas audiofile avi bash-completion berkdb bidi bitmap-fonts bmp bzlib canna cdb cdparanoia cdr cjk crypt cscope cups curl dga dio directfb divx4linux doc dvd dvdread encode esd ethereal exif fam fbcon ffmpeg fftw flac foomaticdb freetds freewn ftp gdbm geoip gif glut gmp gphoto2 gpm gstreamer gtk2 gtkhtml icc icc-pgo iconv ieee1394 imagemagick imap imlib innodb iodbc ipv6 java javascript jikes jpeg kde kdeenablefinal kdexdeltas kerberos ldap libcaca libg++ libwww lirc lm_sensors mad matroska mikmod mime mmx mono motif mozilla mp3 mpeg msn nas ncurses nls nptl odbc offensive ogg oggvorbis opengl oss pam pcmcia pcntl pdflib perl png posix python qt quicktime readline ruby samba scanner sdl snmp sockets socks5 speex spell sse ssl svga symlink tcpd tetex threads tiff truetype truetype-fonts type1-fonts unicode usb v4l vcd vorbis wifi win32codecs wxwindows xine xinerama xml xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

```

avete qualche consiglio da darmi?

ho provato a seguire quello che c'è scritto qui

https://forums.gentoo.org/viewtopic-t-329143-highlight-error+syslibs+glibc2+3+5+toolchainglibcsrccompile+244+exitcode+2.html

ma complice il mio scarso inglese e la poca conoscenza di linux non ho capito molto bene quale sia la soluzione...grazie!

----------

## MonsterMord

Sembra un problema di registri macchina assembler (ma potrei aver detto una grossa cavolta). Come mai hai un kernel per Pentium M (centrino immagino) e le CFLAG per Pentium3?

Ad ogni modo, anche se il processore e' corretto prova a tagliare le opzioni esotiche dalla CFLAGS

----------

## horace

 *MonsterMord wrote:*   

> Sembra un problema di registri macchina assembler (ma potrei aver detto una grossa cavolta). Come mai hai un kernel per Pentium M (centrino immagino) e le CFLAG per Pentium3?
> 
> Ad ogni modo, anche se il processore e' corretto prova a tagliare le opzioni esotiche dalla CFLAGS

 

ho trovato da qualche parte che si risolve tolgiendo l'opzione

```
-fPIC
```

(che tra l'altro non mi ricordo neanche perchè l'avevo messa  :Very Happy:   :Rolling Eyes:  )

non ho la CFLAG per pentium M perchè le gcc 3.3.5 non supportano il pentium M (centrino) e ho quindi settato pentium 3

EDIT: ortografia

----------

## Lucacri

-fPIC dovrebbe essere necessaria per effettuare un buon Prelink, o sbaglio?

----------

## .:chrome:.

 *Lucacri wrote:*   

> -fPIC dovrebbe essere necessaria per effettuare un buon Prelink, o sbaglio?

 

sbagli, e pure alla grande.

PIC = Position Indipendent Code, e non è una cosa da abilitare su un desktop

tornando al problema della compilazione, suggerisco di leggere l'OT che è saltato fuori in questo thread: https://forums.gentoo.org/viewtopic-t-360820.html

----------

## horace

 *Lucacri wrote:*   

> -fPIC dovrebbe essere necessaria per effettuare un buon Prelink, o sbaglio?

 

da http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fverbose_002dasm-1581

 *Quote:*   

> 
> 
> -fpic
> 
>     Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.)
> ...

 

devo dire che quando ho installato, nella scelte delle CFLAGS mi sono fidato di un amico che mi ha consigliato questa opzione, ma non ci ho capito un gran che (cmq ora le glibc si stanno compilando a dovere).

----------

## horace

 *k.gothmog wrote:*   

> 
> 
> tornando al problema della compilazione, suggerisco di leggere l'OT che è saltato fuori in questo thread: https://forums.gentoo.org/viewtopic-t-360820.html

 

grazie, ho letto e terrò presente, ma non ho una gran conoscenza delle USE flag...

potresti fare un esempio della decina di flag base da mantenere nel make.conf? inoltre, come faccio a sapere il significato di una flag se non usando

```
equery uses XXX
```

ma che funziona solo su pacchetti già installati?

----------

## Onip

con 

```
#euse -i elenco_use_da_esaminare
```

ti dice pure se sono globali (==> adatte a stare nel make-conf)

oppure locali ( ==> con un po' di sbatti puoi metterle in /etc/portage/package.use)

Byez

P.S. Volendo puoi anche guardarti ufed

```
#emerge ufed
```

----------

## CRV§ADER//KY

ho googlato un po': *Quote:*   

> To create shared library, you have to use -fPIC or -fpic options beside -shared options. A function in shared library will be placed different address in memory for each program. For that reason we have to generate position indipendent code (PIC). -fPIC option generates larger object file then -fpic. -fpic generates smaller and faster objects. But they will be platform dependent and they will include less debug informations.

  *Quote:*   

> Librerie condivise nel formato ELF
> 
> Le DLL in formato ELF non vengono caricate in indirizzi prefissati di memoria ma possono apparire ad indirizzi diversi a seconda del programma.
> 
> Per far ciò le librerie sono scritte in codice PIC (Position Indipendent Code). Nel codice della libreria non vengono mai generati indirizzi assoluti ma solo relativi, sarà il runtime linker a generare quelli assoluti a tempo di esecuzione..
> ...

 

Da questi articoli sembra che -fPIC sia indispensabile per una libreria condivisa..... ci capisco sempre meno

----------

## .:chrome:.

 *horace wrote:*   

> potresti fare un esempio della decina di flag base da mantenere nel make.conf?

 

capisco benissimo il tuo dubbio. è più che lecito, e non è facile rispondere...

se ti interessa sapere come faccio io, semplicemente tengo in make.conf quelle poche flag che ricorrono in tutti (o buona parte) i pacchetti che uso oppure che influiscono DRASTICAMENTE sulla compilazione. queste ultime potrebbero essere

```
X acpi alsa dmx hal ithreads mmx2 nptl nptlonly pam posix pthreads sse2 threads userlocales xml2 -apm -arts -ipv6 -kde -qt
```

che sono quelle che uso su questo pc.

ed ecco il mio package.use:

```
dev-perl/gtk-perl applet

gnome-base/control-center  gstreamer

gnome-base/gnome cdr dvdr

gnome-base/gnome-vfs hal howl samba

gnome-base/nautilus gstreamer

gnome-extra/nautilus-cd-burner cdr dvdr

mail-client/evolution gstreamer

media-gfx/gimp mng svg wmf

media-libs/gst-plugins -esd

media-video/mplayer cdparanoia dga divx4linux doc dvd dvdread i8x0 mmxext rtc sse2 xvid

media-video/totem dvd

net-fs/samba winbind xml

net-misc/dhcpcd static

net-misc/openssh chroot hpn

net-im/gaim -eds

sys-boot/grub netboot static

sys-fs/udev static

sys-libs/glibc userlocales

sys-libs/pam pam_chroot pam_timestamp

www-client/mozilla moznomail xprint mozsvg

www-client/mozilla-firefox xprint mozdevelop mozsvg

x11-libs/qt -cups

x11-misc/xscreensaver offensive -motif
```

all'inizio ci vuole una pazienza infinita, ma si possono ottenere ottimi risultati ripulendo il sistema alla grande

 *CRV§ADER//KY wrote:*   

> Da questi articoli sembra che -fPIC sia indispensabile per una libreria condivisa..... ci capisco sempre meno

 

PIC è una caratteristica che viene comoda quando si implementano sistemi hardened (infatti nel profilo hardened è ereditata per default)

e poi vorrei farti notare una cosa: questo è preso dall'output di equery uses sys-libs/glibc:

Build Position Independent Code.  Do not utilize this flag unless you know what you're doing.

----------

## CRV§ADER//KY

 *k.gothmog wrote:*   

> PIC è una caratteristica che viene comoda quando si implementano sistemi hardened (infatti nel profilo hardened è ereditata per default)
> 
> e poi vorrei farti notare una cosa: questo è preso dall'output di equery uses sys-libs/glibc:
> 
> Build Position Independent Code.  Do not utilize this flag unless you know what you're doing.

 

...quindi? cosa fanno esattamente? che controindicazioni hanno?

----------

## .:chrome:.

 *CRV§ADER//KY wrote:*   

> ...quindi? cosa fanno esattamente? che controindicazioni hanno?

 

compilano, appunto, Position Indipendentent Code... le librerie vengono strutturate in modo diverso, rispetto alla "norma", e quindi cambia il modo in cui gli eseguibili vengono linkati ad esse.

in realtà è una questione abbastanza complessa, nella quale non voglio nemmeno sbilanciarmi, perché non ho un'idea ben precisa.

quello che conta è che sui sistemi desktop non va bene. tagliamo la testa al toro in questo modo  :Very Happy: 

----------

## SilverXXX

Io ho letto qualcosa (ma non ricordo quindi non chiedetemi precisazioni) e serve; su desktop serve se si usa il prelink, altrimenti toglietelo.

----------

## horace

 *k.gothmog wrote:*   

> 
> 
> ```
> X acpi alsa dmx hal ithreads mmx2 nptl nptlonly pam posix pthreads sse2 threads userlocales xml2 -apm -arts -ipv6 -kde -qt
> ```
> ...

 

ok, proverò a fare così e vedrò come mi trovo...un ultima domanda: per capire quali flag sono ridondanti?

per esempio, nell'altro topic hai scritto

 *Quote:*   

> 
> 
>  - alsa, arts e esd collidono. tutti e tre non li usi di certo quindi che senso ha compilarne il supporto? 

 

come faccio a sapere quali sono le flag ridondanti? e in questo caso specifico cosa è meglio tra alsa,arts e esd (nel mio caso uso kde 3.4)? ho cercato nella wiki ma non ho trovato molto..

scusate l'OT mostruoso  :Very Happy: 

----------

## CRV§ADER//KY

 *horace wrote:*   

>  *Quote:*   
> 
>  - alsa, arts e esd collidono. tutti e tre non li usi di certo quindi che senso ha compilarne il supporto?  
> 
> come faccio a sapere quali sono le flag ridondanti? e in questo caso specifico cosa è meglio tra alsa,arts e esd (nel mio caso uso kde 3.4)? ho cercato nella wiki ma non ho trovato molto..
> ...

 

Al peggio compili della roba inutile. Comunque io ho "alsa -arts -oss -esd" e non ho la minima necessità di altro. Nota che, per le applicazioni che non supportano alsa, puoi comunque abilitare l'emulazione OSS dal kernel.

----------

## SilverXXX

Stiamo semplificando un pò troppo la questione, le use flag vanno messe (sia nel make.conf che in package.use) pensandole bene, possibilmente vedendo pacchetto per pacchetto cosa fanno. arts e esd sono quasi sempre collidenti, ma non alsa con uno dei due (ps con kde si usa arts).

Purtroppo gestirsi per bene tutte le use senza conoscere il pacchetto è impossibile (provate apache, mysql e php: da spararsi, anche per me che un pò li conosco)

----------

## .:chrome:.

 *horace wrote:*   

> come faccio a sapere quali sono le flag ridondanti? e in questo caso specifico cosa è meglio tra alsa,arts e esd (nel mio caso uso kde 3.4)? ho cercato nella wiki ma non ho trovato molto..

 

il discorso è molto semplice: non te ne frega niente (e non devi) specificare tutte le use possibili ed immaginabili. impazziresti...

specifica solo quello che ti interessa e tieniti le standard (che vuol dire non specificare niente, ma tieniti quelle ereditate dal profilo)

----------

## Kernel78

 *k.gothmog wrote:*   

>  *horace wrote:*   come faccio a sapere quali sono le flag ridondanti? e in questo caso specifico cosa è meglio tra alsa,arts e esd (nel mio caso uso kde 3.4)? ho cercato nella wiki ma non ho trovato molto.. 
> 
> il discorso è molto semplice: non te ne frega niente (e non devi) specificare tutte le use possibili ed immaginabili. impazziresti...
> 
> specifica solo quello che ti interessa e tieniti le standard (che vuol dire non specificare niente, ma tieniti quelle ereditate dal profilo)

 

Allora io che sono già pazzo di mio non dovrei aver grossi problemi a specificare tutte le USE  :Wink: 

Scherzi a parte io cerco di specificarne il maggior numero possibile per aver il maggior controllo possibile del mio sistema. Ovviamente uso molto anche il file package.use (es. come standard non voglio la documentazione ma per ruby la voglio) sempre per ottenere il maggior controllo possibile. Per ogni pacchetto che voglio emergere controllo prima le varie USE con cui verrebbe installato e valuto caso per caso se mi conviene modificare quelle globali o quelle specifiche.

Facendo un esempio (banale) con il tuo metodo potrei ignorare la USE doc (e quindi trovarmi di default la documentazione), installando pacchetto per pacchetto mi troverei a constatare che la documentazione non mi serve e a quel punto piuttosto che avere un sacco di pacchetti in package.use per specificare di non installare la documentazione preferisco mettere la use in make.conf (ovviamente dipende da quante eccezioni ci sono  :Smile:  ).

Spero di essermi spiegato in maniera comprensibile.

----------

## .:chrome:.

 *Kernel78 wrote:*   

> Scherzi a parte io cerco di specificarne il maggior numero possibile per aver il maggior controllo possibile del mio sistema.

 

eh sì... ma così facendo corri il rischio di incappare in flag che collidono. a questo punto che fai?

credimi: non è che te lo dico così per sport, ma perché ho provato sulla mia pelle  :Laughing: 

non hai maggior controllo sul sistema, nel momeno in cui includi il supporto a funzioni che non ti servono. trasformi il tuo linux in windows

 *Kernel78 wrote:*   

> Facendo un esempio (banale) con il tuo metodo potrei ignorare la USE doc (e quindi trovarmi di default la documentazione), installando pacchetto per pacchetto mi troverei a constatare che la documentazione non mi serve e a quel punto piuttosto che avere un sacco di pacchetti in package.use per specificare di non installare la documentazione preferisco mettere la use in make.conf (ovviamente dipende da quante eccezioni ci sono  )

 

e invece no. non hai capito cosa voglio dire...

se non vuoi la documentazione IN GENERALE, imposti -doc in make.conf, in modo che faccia da impostazione generale per tutto il sistema, e poi metti solo per i pacchetti che ti interessano doc in package.use

sai perché io ho preso questa strada? perché mi sono trovato davanti a pacchetti che compilavano l'impossibile quando non mi serviva, o con pacchetti php che includevano il supporto al database sbagliato o bacato per colpa di una flag di troppo...

----------

## xchris

il mio consiglio sulle useflag e':

partire da un make.conf con pochissime USE settate (quelle di cui siamo certi...tipo xvid,ipv6,kde....ecc.ecc) sia che siano in negativo che in positivo. (e che si ritengano valide per la maggior parte dei pacchetti e non solo per pochi o addirittura uno)

Lanciare dei

```

emerge --info | grep USE

```

e ripulire togliendo le USEFLAG che si ritengono non necessarie (mettendole nel make.conf con segno -)

mettere le poche USEFLAGS che si ritengono necessarie per pochi pacchetti in package.use.

Utilizzare dei tool per controllare la situazione generale e usare poi emerge --newuse per portarsi ad una situazione coerente.

Avere tante USE in make.conf non e' saggio perche' si rischia di disabilitare alcune USEFLAGS ereditate (che spesso hanno senso di essere ereditate  :Wink: 

Avere tante entry in package.use non è saggio perche' si rallenta notevolmente portage e si perde di vista l'impostazione del sistema.

Ufed e' carino ma penso che porti spesso il noob ad una scelta errata.

(va bene per avere un quadro generale con tutte le descrizioni...o quasi)

Chiaramente IMHO

ciao

----------

## federico

Parlando di poca roba...

```

[100%] blackman@altair ~ $ emerge --info | grep USE

USE="x86 X aalib acpi alsa apache2 avi bitmap-fonts cdr chroot crypt cups curl directfb dvd dvdr emboss encode esd fam fbcon flac foomaticdb fortran freetype gd gdbm gif gnutls gnutsl gpm gtk gtk2 imagemagick imlib ipv6 jack java jpeg junit libg++ libwww mad mikmod mmx motif mp3 mpeg mysql ncurses nls nptl ogg oggvorbis opengl oss pam pcmcia pdflib perl php png postgres python qt quicktime readline samba sdl slang sqlite ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode usb vorbis xine xml xml2 xmms xv zlib linguas_it userland_GNU kernel_linux elibc_glibc"

[100%] blackman@altair ~ $ 

```

----------

## Kernel78

 *k.gothmog wrote:*   

> non hai maggior controllo sul sistema, nel momeno in cui includi il supporto a funzioni che non ti servono. trasformi il tuo linux in windows

 

Su questo siamo d'accordo, io infatti non ho mai detto di includere cose che non servono ma di conoscerne il più possibile e di abilitare/disabilitare il maggior numero.

 *k.gothmog wrote:*   

> sai perché io ho preso questa strada? perché mi sono trovato davanti a pacchetti che compilavano l'impossibile quando non mi serviva, o con pacchetti php che includevano il supporto al database sbagliato o bacato per colpa di una flag di troppo...

 

e sai perchè io sono rimasto su questa strada ? perchè i pacchetti compilavano esattamente quello che volevo io senza il supporto per qualcosa che non mi interessava  :Cool:  Mi spiace che tu non sia riuscito a ottimizzare il sistema in questo modo ma io non sto riscontrando grossi problemi, certo, occorre investire un bel po' di tempo ad imparare quali USE servono e quali no e bisogna farlo prima in installare IMHO.

----------

