[gentoo-amd64] recommended USE flags

[gentoo-amd64] recommended USE flags

[Rafael Barrera Oro]

Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed 
make.conf is full of USE flags (a lot of em really) which every now and 
then cause emerges to merge a lot of packages that i dont need, so i 
wanted to ask if there is an advisable minimum set of flags that i could 
use.

Thanks in advance

Rafael
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Ahmed Ammar]

Have you looked at make.conf.example ?

On 11/08/06, Rafael Barrera Oro <rafael@akyasociados.com.ar> wrote:
> Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> make.conf is full of USE flags (a lot of em really) which every now and
> then cause emerges to merge a lot of packages that i dont need, so i
> wanted to ask if there is an advisable minimum set of flags that i could
> use.
>
> Thanks in advance
>
> Rafael
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Dan Clark]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

Also, check on the gentoo wiki for the use flag how-to that explains what
they are all for. Honestly you don't need that many use flags. The problem
for you now is that you have you system built, which means you may have a
large number of unnecessary addons to many packages, also you may have
complete packages which are not needed. IMHO, depending on how far along
your system build is, it might be easier to re-install the system then to
trim down a  huge number of use flags.

On 8/11/06, Ahmed Ammar <b33fc0d3@gmail.com> wrote:
>
> Have you looked at make.conf.example ?
>
> On 11/08/06, Rafael Barrera Oro <rafael@akyasociados.com.ar> wrote:
> > Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> > make.conf is full of USE flags (a lot of em really) which every now and
> > then cause emerges to merge a lot of packages that i dont need, so i
> > wanted to ask if there is an advisable minimum set of flags that i could
> > use.
> >
> > Thanks in advance
> >
> > Rafael
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 1586 bytes --]

Re: [gentoo-amd64] recommended USE flags

[Sam Barlow]

For researching the USE flags I use I went to http://gentoo-portage.com/

I decided what applications I was going to run looked-up their
dependancies and set my flags based on that.  It also made in much
easier to move the bulk of the flags from make.conf to package.use
[Making some flags not so Global]

On 8/11/06, Dan Clark <danielmclark@gmail.com> wrote:
> Also, check on the gentoo wiki for the use flag how-to that explains what
> they are all for. Honestly you don't need that many use flags. The problem
> for you now is that you have you system built, which means you may have a
> large number of unnecessary addons to many packages, also you may have
> complete packages which are not needed. IMHO, depending on how far along
> your system build is, it might be easier to re-install the system then to
> trim down a  huge number of use flags.
>
>
> On 8/11/06, Ahmed Ammar <b33fc0d3@gmail.com> wrote:
> > Have you looked at make.conf.example ?
> >
> > On 11/08/06, Rafael Barrera Oro <rafael@akyasociados.com.ar> wrote:
> > > Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> > > make.conf is full of USE flags (a lot of em really) which every now and
> > > then cause emerges to merge a lot of packages that i dont need, so i
> > > wanted to ask if there is an advisable minimum set of flags that i could
> > > use.
> > >
> > > Thanks in advance
> > >
> > > Rafael
> > > --
> > > gentoo-amd64@gentoo.org mailing list
> > >
> > >
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
>
>


-- 
Sam Barlow
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Roman Zilka]

> Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed 
> make.conf is full of USE flags (a lot of em really) which every now and 
> then cause emerges to merge a lot of packages that i dont need, so i 
> wanted to ask if there is an advisable minimum set of flags that i could 
> use.
> 
> Thanks in advance
> 
> Rafael

Hi,

IMHO the USE flags setting is what differentiates me from mostly everyone
else - some kind of a DNA of a Gentoo user. I think you'll have to
make yourself a cup of coffee, read the whole of
/usr/portage/profiles/use.desc and decide on your own. Maybe someone might
come up with a set of flags your would probably want to have set, but you're
apparently interested in disabling features to get rid of some unwanted
stuff. And I think there's no telling what flags should be disabled generally.
You have to decide what you want your system to look like, only you know the
environment (network, HW, ...), the apps you'd like to use, etc.

To give you an impression, here's my set of flags and its background:

USE="-3dfx 3dnow X a52 aac -accessibility -acl acpi -afs -aim alsa
-altivec -apm -arts bash-completion -bidi -bluetooth bzip2 -canna
-cdinstall cdr -chasen -cjk -clamav crypt cups curl -debug
-dedicated -directfb -doc dri dv dvd dvdr -emacs -emacs-w3 -emboss
encode -esd -examples exif -fbcon ffmpeg -firefox flac -foomaticdb
-fortran -freewnn ftp -gb gif glut -gnome -gnustep -gphoto2 -gpm gstreamer
gtk2 -guile -ibm iconv icq -ieee1394 imagemagick
imap -ipv6 -jabber -jack java javascript jikes -joystick jpeg jpeg2k
-kde -kdeenablefinal -kerberos -krb4 -ldap -leim -lirc
lm_sensors mad -maildir -mailwrapper -matrox mbox -mcve -migemo mikmod
mime -minimal mmap mmx mng -mono mozilla mp3 mpeg -mpi
-msn -mule -multilib nas ncurses -netboot -nis nls nocd -nocxx nptl
nsplugin -ocaml offensive -ofx ogg openal opengl -pcmcia pcre -pda pdf
-pfpro png posix -ppds -prelude quicktime -radius recode -ruby samba -sasl
-scanner sdl -skey
-smartcard sndfile -snmp -soap sockets -socks5 sox speex spell sse
sse2 ssl svg -symlink sysvipc szip -tcpd theora threads tiff
truetype unicode usb userlocales -v4l vcd -vhosts videos
vorbis -wifi win32codecs wmf xine -xinerama xmms xosd xpm xprint xv xvid
-yahoo zlib"

I would say this is a consistent set, more or less proven by time (at least
it tweaks my Gentoo to do what I expect it to), but be warned that I'm no
Gentoo-guru.:)

Regards
-Roman
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: recommended USE flags

[Duncan]

Roman Zilka <rzilka@gvid.cz> posted 20060811190148.A25483@eniac.gvid.cz,
excerpted below, on  Fri, 11 Aug 2006 19:01:48 +0200:

> IMHO the USE flags setting is what differentiates me from mostly
> everyone else - some kind of a DNA of a Gentoo user. I think you'll
> have to make yourself a cup of coffee, read the whole of
> /usr/portage/profiles/use.desc and decide on your own. Maybe someone
> might come up with a set of flags your would probably want to have set,
> but you're apparently interested in disabling features to get rid of
> some unwanted stuff. And I think there's no telling what flags should be
> disabled generally. You have to decide what you want your system to look
> like, only you know the environment (network, HW, ...), the apps you'd
> like to use, etc.
> 
> To give you an impression, here's my set of flags and its background:

Seconded, and here are mine (the profile defaults may of course add a few
others):

$cat /etc/portage/make.conf/use
################################################################################
#### make.conf USE flags (only) (USE incremental, thus including defaults)
################################################################################

USE="
7zip a52 aac -aalib acpi audiofile alsa amr -apache2 apm arts asf avi
bash-completion bitmap-fonts berkdb bzip2
caps css cdparanoia cdr crypt cups curl
dga divx4linux dlloader dri dts dv dvd dvdr dvdread
encode -esd expat extrafilters
-f77 fam fame ffmpeg flac font-server foomaticdb -fortran
gcc64 -gcj gdbm gif glibc-omitfp -gnome gpm -gstreamer -gtk gtk2
idn imagemagick imlib -ipv6 ithreads
-java jp2 jpeg jpeg2k
kde kdeenablefinal kdehiddenvisibility
lcms -libcaca -libg++ libwww linuxthreads-tls lm_sensors logitech-mouse logrotate lzo lzw lzw-tiff
mad maildir mikmod mjpeg mng motif mp4 mpeg multilib -multislot musicbrainz
-nas ncurses network -nls
nolvm1 nomirrors no-old-linux nptl nptlonly
ogg offensive openexr opengl oss
pam pcre pdf -perl pic png ppds profile python
qt3 -qt4 quicktime
radeon readline
scanner -sdl slang smime speex spell ssl
tcltk -tcpd theora threads tiff truetype truetype-fonts type1 type1-fonts
usb userlocales
vcd vorbis
X x264 xcomposite xine xinerama xml xml2 xmms xpm xrandr xosd xv xvid
yv12
zlib
"

(My make.conf simply includes one file.  That way, if it gets overwritten,
it's very easy to fix.  =8^)  That file then serves as a master file,
simply including several other files, split out by functionality.)

$cat /etc/make.conf
source /etc/portage/make.conf/master

$cat /etc/portage/make.conf/master
source /etc/portage/make.conf/cflags
source /etc/portage/make.conf/features
source /etc/portage/make.conf/fs
source /etc/portage/make.conf/jed
source /etc/portage/make.conf/ldflags
source /etc/portage/make.conf/log
source /etc/portage/make.conf/makeopts
source /etc/portage/make.conf/mirrors
source /etc/portage/make.conf/net
source /etc/portage/make.conf/use
source /etc/portage/make.conf/other

One more, FWIW:

$cat /etc/portage/make.conf/cflags
#########################
#### make.conf C(XX)FLAGS
#########################
# Default "-O2 -pipe"

# normal
CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -combine -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants"
# plus -fPIC
#CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -combine -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -fPIC"
# basic
#CFLAGS="-march=k8 -Os -pipe -frename-registers"
# very basic
#CFLAGS="-march=k8 -O2 -pipe"
# unoptimized
#CFLAGS="-march=k8 -pipe"

# CXXFLAGS: C++ doesn't like -freorder-blocks-and-partition or -combine, so the above minus that for it
# normal
CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants"
# plus -fPIC
#CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -fPIC"
# basic
#CXXFLAGS="${CFLAGS}"

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Hemmann, Volker Armin]

On Friday 11 August 2006 14:29, Rafael Barrera Oro wrote:
> Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> make.conf is full of USE flags (a lot of em really) which every now and
> then cause emerges to merge a lot of packages that i dont need, so i
> wanted to ask if there is an advisable minimum set of flags that i could
> use.

install ufed

as root:
ufed

then go down the list, read the descripition, think about it, decide, next 
flag, read descriptition, think about it, decide ...

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Peter Humphrey]

On Friday 11 August 2006 23:01, Hemmann, Volker Armin wrote:

> install ufed
>
> as root:
> ufed
>
> then go down the list, read the descripition, think about it, decide,
> next flag, read descriptition, think about it, decide ...

I remember reading of a proposed overhaul of the USE flag documentation; has 
anything come of that? At the moment, many flags are described as "adds 
support for foo", but that is woefully inadequate. In some cases it means 
the inclusion of some extra code in packages to handle the data specified 
by the USE flag, whereas in others it implies a wholesale inclusion of 
reams of packages. Examples: 

-- 
~ # grep wmf /usr/portage/profiles/use.desc
wmf - Adds support for the wmf vector image format
~ # grep X /usr/portage/profiles/use.desc
X - Adds support for X11
-- 

In the wmf case, only a small amount of code is affected, but in the X case 
you get the entire X Window System!

Besides, the "adds support for foo" construction reminds me of BASIC 
programs we used to see 25 years ago, in which the programmer had included 
such gems as:

LET X=0;	REM set X to 0

What's needed is a brief explanation of what including foo implies, and I 
thought a plan was in place to do that. I'd be happy to help out with such 
an effort.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: recommended USE flags

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200608121113.01942.prh@gotadsl.co.uk, excerpted below, on  Sat, 12 Aug
2006 11:13:01 +0100:

>  Examples: 
> 
> -- 
> ~ # grep wmf /usr/portage/profiles/use.desc
> wmf - Adds support for the wmf vector image format
> ~ # grep X /usr/portage/profiles/use.desc
> X - Adds support for X11
> -- 
> 
> In the wmf case, only a small amount of code is affected, but in the X case 
> you get the entire X Window System!
> 
> Besides, the "adds support for foo" construction reminds me of BASIC 
> programs we used to see 25 years ago, in which the programmer had included 
> such gems as:
> 
> LET X=0;	REM set X to 0

/Yah!/  Those sorts of programs are always "interesting"!  :(
Unfortunately, the USE flag thing likewise.

> What's needed is a brief explanation of what including foo implies, and I 
> thought a plan was in place to do that. I'd be happy to help out with such 
> an effort.

The trouble, IMO, is in global vs. local flags.  "Support for X", fine,
and as varied as that support might be, that's about as detailed as one
can get in use.desc and stay accurate for all packages.  What's actually
needed is a use.local.desc that includes all packages with all flag
listings and a description of what each does in each package.  If it
means building against xlib, thus not only forcing xlib and its
dependencies in, but potentially meaning the program won't run if X is
hosed (the reason I have -X in package.use for links, I want it to
function as a text browser even -- /especially/ -- when X isn't working,
tho X support would be nice, it's not critical as is the functionality
when X fails), that's /entirely/ different than simply including a few
icons and a *.desktop file, when USE=X, excluding them when USE=-X.

Another example is net-nntp/pan, which I have some personal knowledge of
as I'm not only using it to post this message, but I'm involved upstream. 
The new 0.1xx betas of the 1.0 to be released probably early next month,
make use of USE=gnome to determine whether to pull in and build against
gnomelib (which pulls in a whole host of other gnome foundation
dependencies) or not.  However, the link against gnomelib is used for only
/one/, that's 1 as in /only/ one, thing -- whether pan checks the
configured gnome browser or uses the $BROWSER environmental variable.
That's /all/ it uses it for.  Now even some folks using gnome may prefer
the flexibility of using the $BROWSER var, thus allowing pan to be
configured for a browser other than that configured for gnome.
Additionally, it may be useful to keep such a trival libgnome linkage out,
as with the links/X example above, so pan can continue to be used with
other desktop environments if gnome is screwed up for some reason or
another.

If gnome support meant something rather fancier, say integration of some
gnome applets or something, or at least use of the gnome mimetype database
to determine what to run for all sorts of stuff, not just the browser,
that's rather different than simple browser-choice-determination-only
support, and it'd be nice if there were some way to say exactly what the
USE=gnome actually did.

Be that as it may, I don't believe anything of the sort is likely to
happen for Gentoo in general.  Maybe ufed or similar will integrate such
detailed explanations at some point (I've never used it, maybe it does
now?), but I've seen nothing on gentoo-dev suggesting there's a movement
to support such a thing in general, and I'm sure I would have if there
were serious discussion of such a thing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: recommended USE flags

[Simon Stelling]

Duncan wrote:
> What's actually
> needed is a use.local.desc that includes all packages with all flag
> listings and a description of what each does in each package. 

We already have that documentation.. It's just not written in english
but in bash ;)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: recommended USE flags

[Duncan]

Simon Stelling <blubb@gentoo.org> posted 44DDCE59.5000901@gentoo.org,
excerpted below, on  Sat, 12 Aug 2006 14:49:29 +0200:

> Duncan wrote:
>> What's actually
>> needed is a use.local.desc that includes all packages with all flag
>> listings and a description of what each does in each package. 
> 
> We already have that documentation.. It's just not written in english
> but in bash ;)

In some cases, yes.  However, take that pan example.  The ebuild makes the
dependency on libgnome clear, but it doesn't say the only thing that
dependency does is allow pan to use the browser configured for gnome. 
That's a pretty major entanglement for the benefit, particularly when one
can simply set the $BROWSER var instead, as an alternative.

(BTW, the basis of that example is changing.  Looks like Charles is going
back to having a pan preferences config entry for it.  The point still
stands, tho.  That's an awful big dependency for a relatively small
benefit, and while the ebuild says gnomelib, it says nothing about what
the gnomelib dependency actually /does/.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: recommended USE flags

[Peter Humphrey]

On Saturday 12 August 2006 13:39, Duncan wrote:

> The trouble, IMO, is in global vs. local flags.

Yes, quite so.

> "Support for X", fine, and as varied as that support might be, that's
> about as detailed as one can get in use.desc and stay accurate for all 
> packages. 

I disagree. It's easy enough for use.desc to say "This will pull in the 
whole X-Window System" or "Enables programs to handle WMF files". Or even 
just to include a single-letter G or L prefix to each description as a 
first step.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: recommended USE flags

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200608121835.43684.prh@gotadsl.co.uk, excerpted below, on  Sat, 12 Aug
2006 18:35:43 +0100:

>> "Support for X", fine, and as varied as that support might be, that's
>> about as detailed as one can get in use.desc and stay accurate for all 
>> packages. 
> 
> I disagree. It's easy enough for use.desc to say "This will pull in the 
> whole X-Window System" or "Enables programs to handle WMF files". Or even 
> just to include a single-letter G or L prefix to each description as a 
> first step.

But the thing is, different packages may do different things with a USE
flag.  Support for X is often linking against xlib (as in the example I
gave), but doesn't have to be that major, and (again as in the example)
could be a minor as adding a few icons and *.desktop files.  The only way
to describe the effect of a USE flag on each package, in many cases, is to
do just that, make the description per package, not global.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Hemmann, Volker Armin]

On Saturday 12 August 2006 20:35, Duncan wrote:
> Peter Humphrey <prh@gotadsl.co.uk> posted
> 200608121835.43684.prh@gotadsl.co.uk, excerpted below, on  Sat, 12 Aug
>
> 2006 18:35:43 +0100:
> >> "Support for X", fine, and as varied as that support might be, that's
> >> about as detailed as one can get in use.desc and stay accurate for all
> >> packages.
> >
> > I disagree. It's easy enough for use.desc to say "This will pull in the
> > whole X-Window System" or "Enables programs to handle WMF files". Or even
> > just to include a single-letter G or L prefix to each description as a
> > first step.
>
> But the thing is, different packages may do different things with a USE
> flag.  Support for X is often linking against xlib (as in the example I
> gave), but doesn't have to be that major, and (again as in the example)
> could be a minor as adding a few icons and *.desktop files.  The only way
> to describe the effect of a USE flag on each package, in many cases, is to
> do just that, make the description per package, not global.
>

so instead of a short but useful hint, which is enough in 95% of cases,  
concentrated in two files, you want the user to search all packages and read 
thousands of descriptions just to figure out if he wants the flag or not?

Are you insane?

Oh, and for local-flags, there are several descriptions, have a look at ufed. 
For the global ones 'pulls in X' or 'needed for mp3/wmv/avi support' is 
really enough to know.It does not matter, that the single package does. I 
want them to have wmv/mp3/X support, how they are do it, is the ebuild's 
problem, not mine. I set a flag, the ebuild maintainer has to figure out how 
to react to it.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Vladimir G. Ivanovic]

On Sat, 2006-08-12 at 22:18 +0200, Hemmann, Volker Armin wrote:

> so instead of a short but useful hint, which is enough in 95% of cases,  

His point is precisely that it's NOT useful enough.

> concentrated in two files, you want the user to search all packages and read 
> thousands of descriptions just to figure out if he wants the flag or not?

grep can do that quite efficiently.

> Are you insane?

Are you rude?

-- Vladimir

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Hemmann, Volker Armin]

On Saturday 12 August 2006 22:45, Vladimir G. Ivanovic wrote:
> On Sat, 2006-08-12 at 22:18 +0200, Hemmann, Volker Armin wrote:
> > so instead of a short but useful hint, which is enough in 95% of cases,
>
> His point is precisely that it's NOT useful enough.

for him maybe.

>
> > concentrated in two files, you want the user to search all packages and
> > read thousands of descriptions just to figure out if he wants the flag or
> > not?
>
> grep can do that quite efficiently.
>

you would still have thousands of descriptions, a lot of them redundand, as a 
big pile. There would be NO advantage doing this. Instead of a short 
explanation, you would get tons of useless text...


> > Are you insane?
>
> Are you rude?

yes, maybe?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Peter Humphrey]

On Saturday 12 August 2006 21:58, Hemmann, Volker Armin wrote:
> On Saturday 12 August 2006 22:45, Vladimir G. Ivanovic wrote:

> > His point is precisely that it's NOT useful enough.
>
> for him maybe.

But it is for most of us. I think the most important occasion of use of 
use.desc is on first installation. That file is already quite large and 
intimidating enough for the new user.

> > > concentrated in two files, you want the user to search all packages
> > > and read thousands of descriptions just to figure out if he wants the
> > > flag or not?
> >
> > grep can do that quite efficiently.
>
> you would still have thousands of descriptions, a lot of them redundand,
> as a big pile. There would be NO advantage doing this. Instead of a short
> explanation, you would get tons of useless text...

I agree here; what I'd like to see is just a bit more thought given to 
use.desc, to offer a hint to the growing user as to what to expect to 
happen. A simple G or L flag would go a long way towards this, but it would 
be more helpful to rewrite most of the descriptions with the user's point 
of view in mind. In particular, "Adds support for foo" should be expunged 
entirely. IMHO.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Peter Humphrey]

On Sunday 13 August 2006 09:48, Peter Humphrey wrote:

> "Adds support for foo" should be expunged entirely.

Actually, I think it would do no harm to prohibit the use of the 
words "support" and "provide" entirely for a couple of months, to get 
people to think about what they really mean. That is, if I were the 
dictator of the world :-)

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Simon Stelling]

Hemmann, Volker Armin wrote:
> On Saturday 12 August 2006 22:45, Vladimir G. Ivanovic wrote:
>> On Sat, 2006-08-12 at 22:18 +0200, Hemmann, Volker Armin wrote:
>>> so instead of a short but useful hint, which is enough in 95% of cases,
>> His point is precisely that it's NOT useful enough.
> 
> for him maybe.

I think you misunderstand the entire issue. What's wrong with a more detailed 
description as an addition to the one we already have in use.desc?

> you would still have thousands of descriptions, a lot of them redundand, as a 
> big pile. There would be NO advantage doing this. Instead of a short 
> explanation, you would get tons of useless text...

There would be an advantage, I just doubt it would be worth the effort because 
in most cases reading the ebuild will give you a detailed idea about what it 
does. There are exceptions though, as Duncan pointed out.

>>> Are you insane?
>> Are you rude?
> 
> yes, maybe?

Yes, definitively. You know, you could actually said 'sorry', but that would 
probably be "insane", right?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: recommended USE flags

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200608122218.22034.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sat, 12 Aug 2006 22:18:21 +0200:

> On Saturday 12 August 2006 20:35, Duncan wrote:
>> Peter Humphrey <prh@gotadsl.co.uk> posted
>> 200608121835.43684.prh@gotadsl.co.uk, excerpted below, on  Sat, 12 Aug
>>
>> > I disagree. It's easy enough for use.desc to say "This will pull in the
>> > whole X-Window System" or "Enables programs to handle WMF files". Or even
>> > just to include a single-letter G or L prefix to each description as a
>> > first step.
>>
>> But the thing is, different packages may do different things with a USE
>> flag.  Support for X is often linking against xlib (as in the example I
>> gave), but doesn't have to be that major, and (again as in the example)
>> could be a minor as adding a few icons and *.desktop files.  The only way
>> to describe the effect of a USE flag on each package, in many cases, is to
>> do just that, make the description per package, not global.
> 
> so instead of a short but useful hint, which is enough in 95% of cases,  
> concentrated in two files, you want the user to search all packages and read 
> thousands of descriptions just to figure out if he wants the flag or not?
> 
> Are you insane?

Well, maybe =8^P, but I don't seem to be conveying what I'm trying to say
accurately.  No, I'm NOT saying search all packages and read thousands of
descriptions (and agree, that could be considered insane, tho it's more or
less what one has to do now)...

> Oh, and for local-flags, there are several descriptions, have a look at ufed. 
> For the global ones 'pulls in X' or 'needed for mp3/wmv/avi support' is 
> really enough to know.It does not matter, that the single package does. I 
> want them to have wmv/mp3/X support, how they are do it, is the ebuild's 
> problem, not mine. I set a flag, the ebuild maintainer has to figure out how 
> to react to it.

What I'm suggesting is that use.desc stay more or less as it is, with a
general description for global USE flags.  However, instead of
use.local.desc only having non-global USE flags, have it list all flags
(or split it into two or more files if it gets unmanageably huge) for all
packages, with what they do for that package.

For a quick idea of what the USE flag does in general, then, if it's a
global USE flag, one would check the entry in use.desc which would be
much as it is now. For a better idea of what it does in a particular
package, check the corresponding entry in use.local.desc, which would
describe the effects of the flag on that particular package. That's what
I'm proposing.  Users could just check the general description if that's
all they wanted/needed, and have exactly the same level of info they have
now, with a possible tweak to a description here or there.  If they wanted
to know for example what the gnome flag did in the pan package, however,
they'd look in use.local.desc and see something to the effect of "Builds
against libgnome to let pan use the configured gnome browser."

See, the problem is that a flag, while it generally adds support for
<flagfeature>, can mean very different things in different ebuilds.  An
example is the perl flag.  In some ebuilds, it means build perl bindings. 
In others, it means install documentation for use with perl.  In still
others, it controls building optional package documentation that requires
perl to build -- documentation for the package, not for using it with
perl, but requiring perl to build that documentation.  Those are three
VERY different meanings, applying to different packages, with USE=perl
used to control them.  Having a per-package entry would allow the user to
see precisely which of these the perl flag was used for in a particular
package, or if it was used for something else entirely.  There's simply no
way to convey that with a global description, unless you effectively
include the per-package descriptions right in the global description, of
course making it long enough to do so, which would then leave us without a
way to get a short and concise general description whet that's all that's
needed.

Still think it's insane, or did I actually convey the idea in a way that
makes a bit more sense, now (whether you agree with it or not)? =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: recommended USE flags

[Hemmann, Volker Armin]

On Sunday 13 August 2006 12:20, Duncan wrote:

>
> > Oh, and for local-flags, there are several descriptions, have a look at
> > ufed. For the global ones 'pulls in X' or 'needed for mp3/wmv/avi
> > support' is really enough to know.It does not matter, that the single
> > package does. I want them to have wmv/mp3/X support, how they are do it,
> > is the ebuild's problem, not mine. I set a flag, the ebuild maintainer
> > has to figure out how to react to it.
>
> What I'm suggesting is that use.desc stay more or less as it is, with a
> general description for global USE flags.  However, instead of
> use.local.desc only having non-global USE flags, have it list all flags
> (or split it into two or more files if it gets unmanageably huge) for all
> packages, with what they do for that package.
>
> For a quick idea of what the USE flag does in general, then, if it's a
> global USE flag, one would check the entry in use.desc which would be
> much as it is now. For a better idea of what it does in a particular
> package, check the corresponding entry in use.local.desc, which would
> describe the effects of the flag on that particular package. That's what
> I'm proposing.  Users could just check the general description if that's
> all they wanted/needed, and have exactly the same level of info they have
> now, with a possible tweak to a description here or there.  If they wanted
> to know for example what the gnome flag did in the pan package, however,
> they'd look in use.local.desc and see something to the effect of "Builds
> against libgnome to let pan use the configured gnome browser."

but we already have that!

Start ufed. Read some of the flag descriptions. For a lot of them, there are 
several ones.

avahi has since descriptions - for six different packages, or atm, two 
descriptions, audacious, three... for each package a different one.


>
> See, the problem is that a flag, while it generally adds support for
> <flagfeature>, can mean very different things in different ebuilds.  An
> example is the perl flag.  In some ebuilds, it means build perl bindings.
> In others, it means install documentation for use with perl.  In still
> others, it controls building optional package documentation that requires
> perl to build -- documentation for the package, not for using it with
> perl, but requiring perl to build that documentation.  Those are three
> VERY different meanings, applying to different packages, with USE=perl
> used to control them.  Having a per-package entry would allow the user to
> see precisely which of these the perl flag was used for in a particular
> package, or if it was used for something else entirely.  There's simply no
> way to convey that with a global description, unless you effectively
> include the per-package descriptions right in the global description, of
> course making it long enough to do so, which would then leave us without a
> way to get a short and concise general description whet that's all that's
> needed.
>
> Still think it's insane, or did I actually convey the idea in a way that
> makes a bit more sense, now (whether you agree with it or not)? =8^)

for local flags it is already done - and global flags... is such an amount of 
information really needed?

If I have perl installed, why should I not want perl bindings, perl 
documentation and perl support in a package? Or pan - if I have gnome 
installed, why should I deactivate gnome support? 'It has gnome support, 
fine' why should I need more information? And if I really need to know, what 
gnome support means, I can always look into the ebuild.

Lots of information is a nice thing, but too much of it is not good either. 
Struck dead by the amount of information... (Er wurde von der Last des 
Wissens erschlagen.) it can happen, and it does happen. ufeds informations 
are already on the verge of getting to much - removing some here and there 
would be helpfull (like three of the 6 avahi comments), because you won't get 
to the end, if you have to read all of it.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: Re: recommended USE flags

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200608131856.11003.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sun, 13 Aug 2006 18:56:10 +0200:

>> For a quick idea of what the USE flag does in general, then, if it's a
>> global USE flag, one would check the entry in use.desc which would be
>> much as it is now. For a better idea of what it does in a particular
>> package, check the corresponding entry in use.local.desc, which would
>> describe the effects of the flag on that particular package. That's what
>> I'm proposing.  Users could just check the general description if that's
>> all they wanted/needed, and have exactly the same level of info they
>> have now, with a possible tweak to a description here or there.  If they
>> wanted to know for example what the gnome flag did in the pan package,
>> however, they'd look in use.local.desc and see something to the effect
>> of "Builds against libgnome to let pan use the configured gnome
>> browser."
> 
> but we already have that!
> 
> Start ufed. Read some of the flag descriptions. For a lot of them, there
> are several ones.
> 
> avahi has since descriptions - for six different packages, or atm, two
> descriptions, audacious, three... for each package a different one.

You mean like this?

$grep avahi use.local.desc
gnome-base/gnome-vfs:avahi - Support for avahi mdns daemon.
media-sound/mt-daapd:avahi - Use avahi instead of howl as mdns daemon
media-sound/pulseaudio:avahi - Use avahi instead of howl as mdns daemon
media-sound/rhythmbox:avahi - support for avahi mdns daemon
media-video/vlc:avahi - Support for avahi mdns daemon.
net-dns/avahi:bookmarks - Install the avahi-bookmarks application (requires dev-python/twisted)
net-dns/avahi:howl-compat - Enable compat libraries for howl
net-dns/avahi:mdnsresponder-compat - Enable compat libraries for mDNSResponder
net-im/ekiga:avahi - Support for the avahi mdns daemon
net-im/gaim:avahi - Enable using avahi howl libraries.
net-misc/vino:avahi - Build with avahi support
sys-auth/nss-mdns:avahi - enable support for Avahi
$grep audacious use.local.desc
app-admin/conky:audacious - enable monitoring of audio tracks that are playing (media-sound/audacious)
app-emulation/uade:audacious - Enables support for media-sound/audacious
media-sound/audacious:chardet - Character set detection support for non-compliant ID3 tags
media-sound/audacious:modplug - Build with modplug support
media-sound/audacious:musepack - Build with musepack support
media-sound/audacious:sid - Build with SID (Commodore 64 Audio) support
media-sound/audacious:timidity - Build with Timidity++ (MIDI sequencer) support
media-sound/audacious:wma - Build with WMA (Windows Media Audio) support
net-irc/xchat-xsys:audacious - Enables Audacious (media player) integration

Those are local USE flags, not global.  What I'm proposing is similar
per-package detail for global USE flags as well.
 
> for local flags it is already done - and global flags... is such an
> amount of information really needed?

Arguably, yes.  If I know what the USE flag enables, both in terms of
dependencies and in terms of per-package functionality (not always the
same thing, see below), I can make a better per-package choice as to
whether I want the flag enabled for that package or not.
 
> If I have perl installed, why should I not want perl bindings, perl
> documentation and perl support in a package?

Because they are three different things.  If you don't know perl yourself,
you have no use for where the flag enables perl documentation and
examples, but could very well have a use for the documentation built using
perl for an otherwise non-perl related package.  The flip could also be
the case -- you want the perl docs, but have no interest in the extra docs
for some package you aren't actually developing with, just using, anyway. 
Both of those are totally separate from perl bindings, which again, might
be needed for something totally unrelated to you actually knowing how to
program perl, or wanting the docs built using perl for some other package
you just use in a pre-built script.


> Or pan - if I have gnome installed, why should I deactivate gnome support? 'It has gnome support,
> fine' why should I need more information? And if I really need to know,
> what gnome support means, I can always look into the ebuild.

No, you /can't/ just look in the ebuild, because as I already said, the
ebuild simply says it uses libgnome, not /why/ it uses libgnome.  Perhaps
you want to be able to configure what browser it uses separately from the
browser you configure for the rest of gnome.  Knowing that's the /only/
thing the gnome support does, you might not want to build it in,
particularly when doing so means if your libgnome ever goes haywire, so
does pan.  If the added functionality is so minor, and you've had issues
with gnome before, there's a case to be made for not wanting to take that
risk.  However, you gotta /know/ that's all it does, before you can make
that informed choice. 

> Lots of information is a nice thing, but too much of it is not good
> either. Struck dead by the amount of information... (Er wurde von der
> Last des Wissens erschlagen.) it can happen, and it does happen. ufeds
> informations are already on the verge of getting to much - removing some
> here and there would be helpfull (like three of the 6 avahi comments),
> because you won't get to the end, if you have to read all of it.

See, that's why I suggested keeping use.desc essentially as it is. 
Newbies and those who don't want the extra information then don't have to
deal with it.  When someone like me comes along that wants to know exactly
what a particular flag does in a package, the (separate) per-package
description file would be there to be used.

The idea is that people that want the brief description use one file,
those that want the details use the other, so everybody gets what they
want/need.

(As for the "insane" thing, I /did/ catch your meaning and didn't take
offense, so no problem here.  However, I know from experience how hard it
can be to apologize, as it's something I've had to work on, so thanks for
catching the potential before it even had a chance to blow up worse. Too
bad not everybody is as willing or quick with misunderstandings. Too many
time's I've seen good people driven away, because both sides refused to
back down over something pretty petty, all in all.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: recommended USE flags

[Hemmann, Volker Armin]

Hi,

sorry for the 'are you insane'.

I did not realize, that such a harmless  question (in a face to face 
discussion), might come around in such way on a mailing list.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Conway S. Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hemmann, Volker Armin wrote:
> On Friday 11 August 2006 14:29, Rafael Barrera Oro wrote:
>> Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
>> make.conf is full of USE flags (a lot of em really) which every now and
>> then cause emerges to merge a lot of packages that i dont need, so i
>> wanted to ask if there is an advisable minimum set of flags that i could
>> use.
> 
> install ufed
> 
> as root:
> ufed
> 
> then go down the list, read the descripition, think about it, decide, next 
> flag, read descriptition, think about it, decide ...
> 

As far as I can tell, ufed doesn't support /etc/portage/package.use.
I'd personally prefer to set most of my USE flags on a per-package
basis.  If ufed supported that, it would probably be much more appealing
to me.  Anyone know if there's plans for adding that functionality to
ufed?  I might do it myself, but if someone has/is planning to, I'd just
as soon not reinvent the wheel.


Conway S. Smith
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE4GmyGL3AU+cCPDERAgyRAJ9sp29FoLY412bX7bRMdYejMZcM0QCgqpIx
o1h4TFazFtk6YwVzXSBxhEM=
=Aczk
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Richard Fish]

On 8/11/06, Rafael Barrera Oro <rafael@akyasociados.com.ar> wrote:
> Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> make.conf is full of USE flags (a lot of em really) which every now and
> then cause emerges to merge a lot of packages that i dont need, so i
> wanted to ask if there is an advisable minimum set of flags that i could
> use.

I would recommend putting very few flags in make.conf, and making
heavy use of /etc/portage/package.use.  In many cases, we add a flag
to make.conf because we want functionality for a single package, and
it ends up affecting other packages as well.  Those flags that do go
in make.conf should truly have some global sense.

A good plan for trimming: for each flag in make.conf, do "USE=-flag
emerge -DNvp world".  If only one or two installed packages use that
flag, move it it package.use.  You also get a chance to possibly
rebuild some things without those flags to eliminate some
dependancies.

-Richard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[J'raxis 270145]

At 2006-08-12T00:05:48+0000, <bigfish@asmallpond.org> wrote:

> Date: Fri, 11 Aug 2006 17:05:48 -0700
> From: Richard Fish <bigfish@asmallpond.org>
> Reply-to: gentoo-amd64@lists.gentoo.org
> Subject: Re: [gentoo-amd64] recommended USE flags
> To: gentoo-amd64@lists.gentoo.org
> Message-ID: <7573e9640608111705o35864357v8283ee9d0557efa3@mail.gmail.com>
> 
> On 8/11/06, Rafael Barrera Oro <rafael@akyasociados.com.ar> wrote:
> >Hello people, i installed a Gentoo 2006.0 with a LiveCD and i noticed
> >make.conf is full of USE flags (a lot of em really) which every now and
> >then cause emerges to merge a lot of packages that i dont need, so i
> >wanted to ask if there is an advisable minimum set of flags that i could
> >use.
> 
> I would recommend putting very few flags in make.conf, and making
> heavy use of /etc/portage/package.use.  In many cases, we add a flag
> to make.conf because we want functionality for a single package, and
> it ends up affecting other packages as well.  Those flags that do go
> in make.conf should truly have some global sense.
> 
> A good plan for trimming: for each flag in make.conf, do "USE=-flag
> emerge -DNvp world".  If only one or two installed packages use that
> flag, move it it package.use.  You also get a chance to possibly
> rebuild some things without those flags to eliminate some
> dependancies.

You can also use equery to determine this, for example:

	# equery hasuse ldap

	[ Searching for USE flag ldap in all categories among: ]
	* installed packages
	[I--] [  ] app-admin/sudo-1.6.8_p9-r2 (0)
	[I--] [  ] net-proxy/squid-2.5.12-r1 (0)
	[I--] [  ] dev-libs/cyrus-sasl-2.1.21-r2 (2)
	[I--] [  ] dev-libs/apr-util-0.9.12 (0)
	[I--] [  ] net-fs/samba-3.0.22-r3 (0)
	[I--] [  ] net-dns/bind-9.3.2 (0)
	[I--] [  ] net-misc/openssh-4.3_p2-r1 (0)
	[I--] [  ] net-misc/curl-7.15.1-r1 (0)

(equery is part of app-portage/gentoolkit.)

-- 
J'raxis 270145
http://www.jraxis.com/
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Peter Humphrey]

On Saturday 12 August 2006 21:18, J'raxis 270145 wrote:
> At 2006-08-12T00:05:48+0000, <bigfish@asmallpond.org> wrote:

> > A good plan for trimming: for each flag in make.conf, do "USE=-flag
> > emerge -DNvp world".  If only one or two installed packages use that
> > flag, move it it package.use.  You also get a chance to possibly
> > rebuild some things without those flags to eliminate some
> > dependancies.
>
> You can also use equery to determine this, for example:
>
> 	# equery hasuse ldap
>
> 	[ Searching for USE flag ldap in all categories among: ]
> 	* installed packages
> 	[I--] [  ] app-admin/sudo-1.6.8_p9-r2 (0)
> 	[I--] [  ] net-proxy/squid-2.5.12-r1 (0)
> 	[I--] [  ] dev-libs/cyrus-sasl-2.1.21-r2 (2)
> 	[I--] [  ] dev-libs/apr-util-0.9.12 (0)
> 	[I--] [  ] net-fs/samba-3.0.22-r3 (0)
> 	[I--] [  ] net-dns/bind-9.3.2 (0)
> 	[I--] [  ] net-misc/openssh-4.3_p2-r1 (0)
> 	[I--] [  ] net-misc/curl-7.15.1-r1 (0)
>
> (equery is part of app-portage/gentoolkit.)

I think it should be supplemented with a tool that would scan the entire 
database of packages, not just the ones installed. Whenever I'm considering 
a change, of whatever sort, I want to know the consequences.

Unless I'm mistaken, there's no way to find out what USE flags a package 
uses without installing it first. I recently discovered gentoo-portage.com, 
which is useful but it's organised the other way around, naturally enough, 
so it still involves much scanning.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Simon Stelling]

Peter Humphrey wrote:
> Unless I'm mistaken, there's no way to find out what USE flags a package 
> uses without installing it first. I recently discovered gentoo-portage.com, 

$ emerge -pv seahorse

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] app-crypt/seahorse-0.7.8  USE="-debug -ldap" 1,090 kB


-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] recommended USE flags

[Peter Humphrey]

On Sunday 13 August 2006 11:20, Simon Stelling wrote:

> $ emerge -pv seahorse

Hah!

Yes, of course. Thanks. Looks like my lateral thinking was behind me.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list