# HOWTO (Experiment): Slim down by removing USE flags

## termite

I hope this will eventually morph into a comprehensive HOWTO as to what USE flags you can live without.  This started from a little experiment: I don't use gnome (I'm a KDE guy), so I figured I'd set 

```
-gnome
```

 in my make.conf and see what happens when I 

```
emerge -avutND world

emerge --depclean -a

revdep-rebuild -av
```

After a long recompile of lots of packages (incl Firefox and Thunderbird, ARGH!), I got to input the second command.  It wanted to remove 41 (!!!!) libraries.  Oh well, I thought, we'll see what revdep will just end up bringing back.  So I pressed enter and presto, 41 libraries disappeared in a puff of smoke (well, I imagined the smoke, real smoke would have been bad  :Wink:  ).

I started the revdep command and waited.  I came back with a cup of coffee and stared at the screen in amazement: It didn't want to do anything!  I had just cleaned out 41 entirely useless libraries!

Needless to say, I was pretty pleased with myself.  Maybe I can clean out more USE flags and get rid of more....

Update: Got rid of berkdb USE flag.  Lots of recompiling, but emerge --depclean -a didn't want to get rid of anything.  I think I need to get rid of evolution before much will happen.  See update 5 below.

Update 2: Getting rid of evo didn't require any recompiling.  I think it's only used by gnumeric and multisync.

Update 3: Got rid of ldap.  Lots of recompiling, one package (openldap, duh) removed by emerge --depclean -a.  Revdep-rebuild is re-emerging subversion, gconf and xxdiff.  Nothing new, just more recompiling.

Update 4: Getting rid of mikmod required no further work, just like evo.

Update 5: Getting rid of eds (evolution data server) required only Pidgin to be recompiled.  4 packages were removed by emerge --depclean -a, including sys-libs/db! Revdep-rebuild found that something broke Python, so is recompiling.

Update 6: Removing emboss required no further work.

Update 7: Removing libnotify required vlc to be recompiled.  Seven packages were removed by emerge --depclean -a.  At this point, I have a minimal number of gnome-dependencies (just libglade and libgsf)!  Revdep-rebuild found that imagemagick and gtk-engines-qt were broken and is now recompiling.

Now for a request from all of you readers: if you have some time on your hands, start getting rid of flags and report back here as to your results.  Please report:

What USE flag you got rid of

How many libraries 

```
emerge --depclean -a
```

 got rid of

How many (if any) libraries 

```
revdep-rebuild -av
```

 restored

IMPORTANT: any breakage.

Please do this one flag at a time so that results can be assessed reliably.  Please also be careful.  Don't remove essential flags (see http://www.gentoo.org/dyn/use-index.xml).  

I hope to eventually turn this into a big table on the wiki so that people can have a resource accessible if they want to do some slimming down.

Thanks everybody! (especially to didymos who inspired me to get rid of the gnome USE flag!)Last edited by termite on Mon Aug 06, 2007 6:45 pm; edited 6 times in total

----------

## Sadako

I already have quite a slimmed down setup, so I can't contribute, however I thought it would be worth pointing out that if you want to start off with minimal use flags, you should try not using the default "desktop" profiles, which just contain a lot of extra use flags.

IMO these profiles are bloated and should only be used by those who simply don't understand use flags yet or aren't sure which they need for a desktop system (n00bs  :Wink:  ).

Run `eselect profile list` to see what valid profiles you have, and say for example you're using "default-linux/amd64/2007.0/desktop", try switching to plain "default-linux/amd64/2007.0", run `source /etc/profile`, and `emerge -puDN world`, and see if you like what you get.

----------

## termite

I am indeed using the 2007.1 Desktop profile, since I am a relatively recent Gentoo convert and am only beginning to understand USE flags (hence this experiment).  I want to start from the profile and subtract, though, so there can be useful results for other recent n00bs...

----------

## mounty1

```
cd /var/db/pkg

for I in */*;do equery uses =$I;done | grep '^\+' | sort | uniq
```

will tell you what flags are used by your installed set.  Compare with /etc/make.conf USE= and you know what can go.

----------

## i92guboj

 *Hopeless wrote:*   

> 
> 
> IMO these profiles are bloated and should only be used by those who simply don't understand use flags yet or aren't sure which they need for a desktop system (n00bs  ).
> 
> 

 

Was that meant to be a sempiternal absolute affirmation or can it be translated as "It is the way I like it, for me"?

Everyone can use any profile, as long as it fulfills his/her purpose with a shorter list in make.conf and/or packages.use. Those not allergic to gtk, qt or functionality in general, might find that having a desktop profile will result in a shorter list of flags in the package.use file. Remember, USE flags can also be set/unset regardless of the profile. You should always pick the profile that is  closer to the end results you need, regardless of the noobish it can seem.

I, myself, use the desktop profile, believe me, I don't know every single ./configure option for every single program, but I have a more than average idea about use flags and what they do/can do.  :Wink: 

----------

## termite

After my experience today, I agree that the desktop profile is bloated.  I got rid of around 90 packages that were sitting around doing nothing useful.

I don't object to the desktop profile being around, but it would be nice if the installation guide would mention that it tends to install a lot of stuff that users may not need.

----------

## Sadako

 *i92guboj wrote:*   

>  *Hopeless wrote:*   
> 
> IMO these profiles are bloated and should only be used by those who simply don't understand use flags yet or aren't sure which they need for a desktop system (n00bs  ).
> 
>  
> ...

 IMO, abbreviated form of "in my opinion", generally used to acknowledge that a statement is a personal opinion rather than an undeniable fact.

But you do get bonus points for use of the word "sempiternal", so it's all good.

 :Smile: 

----------

## micr0c0sm

Note the -* which first removes all use flags. There is also the 'minimal' use flag but I am not sure if that is overridden by the other ones. 

```

# cat /etc/paludis/use.conf

*/* -* X acpi alsa bash-completion bzip2 cdparanoia cdr dbus dvd dvdr dvdread

*/* gif glitz jpeg mmap mmx mp3 mpeg nls nptl offensive ogg opengl pdf png quicktime

*/* readline ruby sse sse2 ssl svg symlink threads win32codecs x264 xvid zlib

*/* LINGUAS: -* en

*/* INPUT_DEVICES: -* evdev keyboard mouse

*/* VIDEO_CARDS: -* nvidia

```

```

# paludis -i everything --dl-reinstall if-use-changed -p | grep minimal

* sys-libs/ncurses-5.6-r2 {:5} [R] -bootstrap -build -debug -doc -gpm* minimal* -nocxx -profile -trace -unicode* <everything, system> <app-editors/nano-2.0.6::gentoo, app-misc/screen-4.0.3::installed, 19 more>

* app-editors/nano-2.0.6 {:0} [R] -debug -justify minimal* -ncurses* nls -slang -spell -unicode* <everything> <virtual/editor-2.0.6::installed_virtuals>

* x11-apps/xinit-1.0.4 {:0} [R] -debug minimal* <everything> <x11-base/xorg-server-1.3.0.0::gentoo>

* x11-base/xorg-server-1.3.0.0 {:0} [R] -3dfx -debug -dmx -dri -ipv6 -kdrive minimal* nptl -sdl xorg -xprint input_devices: -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300 -elographics evdev -fpit -hyperpen -jamstudio -joystick keyboard -magellan -microtouch mouse -mutouch -palmax -penmount -spaceorb -summa -synaptics -tek4957 -ur98 -vmmouse -void -wacom video_cards: -apm -ark -chips -cirrus -cyrix -dummy -epson -fbdev -fglrx -glint -i128 -i740 -i810 (-impact) -imstt -mach64 -mga -neomagic (-newport) -nsc -nv nvidia -r128 -radeon -rendition -s3 -s3virge -savage -siliconmotion -sis -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tdfx -tga -trident -tseng -v4l -vesa -vga -via -vmware -voodoo <everything> <x11-drivers/nvidia-drivers-100.14.11::installed, x11-drivers/xf86-input-evdev-1.1.5-r1::installed, 3 more>

* xfce-base/xfdesktop-4.4.1-r1 {:0} [R] dbus -debug -doc minimal* linguas: -be -ca -cs -da -de -el -es -et -eu -fi -fr -he -hu -it -ja -ko -nl -pa -pl -pt_BR -ro -ru -sk -sv -tr -uk -vi -zh_CN -zh_TW <everything>

* xfce-extra/xfburn-0.3.0_pre20070616 {:0} [R] -debug minimal* <everything>

```

All in all just 6 rebuilds, but I am gonna stay away from minimal just because i like pretty fonts.

----------

## mope

I once tried to do a minimalist environment like this. I started with -* and built from there.

Keep in mind that the dependencies of various packages will change the amount to be emerged per person so the fact that you take one USE flag off and re-emerge 40 packages doesn't mean that the next person will get the same result. It doesn't even mean *you* would get the same result if you change the order you change your USE flags.

Anyway, after a long time of discussing with users and a couple devs, where I expressed concern that the descriptions for the various USE flags were lacking, I learned two things: 1) my time would be better spent focusing on the USE flag descriptions so people could decide for themselves what is essential or not, and 2) the profiles are *generally* acceptable for the most people.

I think it's great you're experimenting with your new OS, but how do you know what you'll need already?

For example, did you just decide to rip out gnome libaries because you don't like/use gnome, or do you actually *know* what USE=gnome for mozilla-firefox does?

----------

## termite

Personally, I decided to get rid of the gnome flag because I believe that larger applications (eg window managers) should be relatively independent of one another.  This was one of the reasons I switched from Windows to Linux.  The MS idea of 'integration' seems to be making everything dependent on each other, making flexibility in installation very tricky.  All the various Windows 'lite' projects ended up taking away a lot of functionality.  While I'd love a detailed description of what every use flag does to every program (especially the big programs and the major use flags), I haven't noticed any reduction in functionality due to all the flags I disabled.

There was one exception to this.  Using udept, I noticed that there were a huge number of gnome libraries installed just due to Miro/Democracy Player.  I got rid of Miro (I don't use it much and it's buggy as hell) in order to clean them out.  Personally, I think that Miro is badly designed: there should be options to use KDE (or XFCE, etc) libraries instead.  That's what I like about Gentoo: I can choose these things.

Use flags are a pretty amazing idea.  I think they need far better documentation and would love to work on getting that done.  However, I'm not a programmer.  If anyone has good ideas as to how to do this, please post.

----------

## mope

 *termite wrote:*   

> Personally, I decided to get rid of the gnome flag because I believe that larger applications (eg window managers) should be relatively independent of one another. 

 

They are independent of one another.

*Applications* are not dependent upon "one another" either, if that's what you meant.

If developers didn't reuse toolkits they'd have to recode common repititious tasks, resulting in bloated code and increased bugs.

gnomelibs != gnome

 *Quote:*   

> All the various Windows 'lite' projects ended up taking away a lot of functionality. 

 

That's going to happen as you continue to strip standard USE flags out, too...

 *Quote:*   

> 
> 
> While I'd love a detailed description of what every use flag does to every program (especially the big programs and the major use flags), I haven't noticed any reduction in functionality due to all the flags I disabled.
> 
> 

 

How long have you been using the programs you've altered?

 *Quote:*   

> Personally, I think that Miro is badly designed: there should be options to use KDE (or XFCE, etc) libraries instead.  That's what I like about Gentoo: I can choose these things.
> 
> 

 

No, you can't choose "these things" [for an app to use KDE instead of gnome libraries] in Gentoo...nor would anyone want to after learning more about what is going on under the hood.

 *Quote:*   

> 
> 
> Use flags are a pretty amazing idea.  I think they need far better documentation and would love to work on getting that done.  However, I'm not a programmer.  If anyone has good ideas as to how to do this, please post.

 

No need to be a programmer, start by reading the ebuilds and man pages...

----------

## i92guboj

 *mope wrote:*   

>  *termite wrote:*   Personally, I decided to get rid of the gnome flag because I believe that larger applications (eg window managers) should be relatively independent of one another.  
> 
> They are independent of one another.
> 
> *Applications* are not dependent upon "one another" either, if that's what you meant.
> ...

 

This is the whole point that people complaining about "how heavy toolkits are" do not understand at all.

As you say, toolkits are there to avoid duplication, triplication and re-re-replication of the same functionality. Additionally, if a bug is found, it is fixed in the toolkit, and that fixes it for ALL the applications using the toolkit. That is how the designs gets more solid with time, and not replicating code all around the way, that will do the same. Learn one thing: dynamic linking to a library or a toolkit is not a bad thing, it will make the size of applications smaller.

Some people seem to think that when you open a QT/Gtk base program, every single bit of the toolkit is suddenly loaded into memory, while the truth is that only the relevant .so files are read and loaded.

More below.

 *Quote:*   

>  *Quote:*   All the various Windows 'lite' projects ended up taking away a lot of functionality.  
> 
> That's going to happen as you continue to strip standard USE flags out, too...
> 
> 

 

It just depends on the case. On most packages, the kde and gnome use flags are something idiotic, that just creates an entry in a desktop/context menu, or activates any other silly integration with each of these desktops. The gtk and qt flags are generally only available on those packages that can have frontends/functionalities for the two toolkits (toolkits or desktops are different things, and totally unrelated except for the ones developing the desktop itself). Of course, only a view at the ebuild file will show what a given flag does on a given package.

 *Quote:*   

> 
> 
>  *Quote:*   Personally, I think that Miro is badly designed: there should be options to use KDE (or XFCE, etc) libraries instead.  That's what I like about Gentoo: I can choose these things.
> 
>  
> ...

 

Right. To choose to compile an application with qt (the KDE toolkit) or gtk (the gnome/xfce toolkit) is not as simple as just wishing it. To use gtk in a program you actually need to program it in gtk. There is no way that a gtk program can be compiled for qt, or vice-versa. You can't choose this in gentoo nor in any other OS. If a program uses a library or toolkit, you just can't compile it without that toolkit. That is why the kde programs do not have a qt use flag: they just need qt, it is out of the question, it is not an optional thing.

----------

## termite

 *Quote:*   

> They are independent of one another.
> 
> *Applications* are not dependent upon "one another" either, if that's what you meant.

 

That depends on the profile!  If one uses the Desktop profile, one gets the impression that you cannot live in KDE without gnomelibs, which is just not true.

 *Quote:*   

> gnomelibs != gnome 

 

Fair enough, but why should I need gnomelibs in KDE?  Both gnomelibs and kdelibs are fairly heavy libraries, which require quite a lot of time to compile.  Why should I be required to use gnomelibs if I'm not using gnome?  As I said before, the only app that completely failed to function after removing a bunch of gnome libraries was Miro.  Everything else I use (web browser, im, media player, desktop widgets, email client, plus basic stuff that comes with both KDE and gnome) functions absolutely fine without them.

 *Quote:*   

> That's going to happen as you continue to strip standard USE flags out, too... 

 

Which is why we need detailed descriptions of the effects of those USE flags on various programs, at least the major standards.

I can choose to not have my firefox build depend on gnome libraries.  If someone had a decent description of what the gnome USE flag does, that choice would be more informed.  As of now, FF feels fine to me without it.

Edit: After some digging, I found that disabling the gnome USE flag on firefox disables the following 

```
--disable-gnomevfs      Disable GnomeVFS support

--disable-gnomeui      Disable libgnomeui support (default: auto, optional at runtime)
```

As a non-programmer, I have next to no idea what these things mean.  Googling gnomevfs tells me that it's the 'file system abstraction library'.  Again, I have no idea what that means.  USE flag documentation is therefore necessary for informed choice.

 *Quote:*   

> No need to be a programmer, start by reading the ebuilds and man pages...

 

True, but going through a tree of ebuilds isn't everyone's cup of tea.  Providing documentation would make things easier for most users.  I don't see why anyone objects to this.

 *Quote:*   

> Right. To choose to compile an application with qt (the KDE toolkit) or gtk (the gnome/xfce toolkit) is not as simple as just wishing it. To use gtk in a program you actually need to program it in gtk. There is no way that a gtk program can be compiled for qt, or vice-versa. You can't choose this in gentoo nor in any other OS.

 

You can choose this if programmers develop cross-platform applications.

 *Quote:*   

> If a program uses a library or toolkit, you just can't compile it without that toolkit. That is why the kde programs do not have a qt use flag: they just need qt, it is out of the question, it is not an optional thing.

 

Right, but if I'm running gnome and no kde programs, I shouldn't need any qt or kde libs.  Ditto for running kde and no specific gnome progs.

----------

## i92guboj

 *Quote:*   

>  *Quote:*   gnomelibs != gnome  
> 
> Fair enough, but why should I need gnomelibs in KDE?  Both gnomelibs and kdelibs are fairly heavy libraries, which require quite a lot of time to compile.  Why should I be required to use gnomelibs if I'm not using gnome?  As I said before, the only app that completely failed to function after removing a bunch of gnome libraries was Miro.  Everything else I use (web browser, im, media player, desktop widgets, email client, plus basic stuff that comes with both KDE and gnome) functions absolutely fine without them.
> 
> 

 

I bet you don't need gnomelibs for any kde component. If gnomelibs are pulled as deps it is because some program has optional support for gnomelibs or needs them for something. Of course, if you don't need that, you can turn it on via use flag, if one use flag is available for that in that concrete program.

 *Quote:*   

> 
> 
> I can choose to not have my firefox build depend on gnome libraries.  If someone had a decent description of what the gnome USE flag does, that choice would be more informed.  As of now, FF feels fine to me without it.
> 
> 

 

Weird. Note that the firefox ebuilds DO NOT HAVE a gnome use flag. You can check yourself:

```

$ cd /var/portage/www-client/mozilla-firefox/ && grep gnome *

ChangeLog:  just gnome.

ChangeLog:    /usr/share/applications instead of /usr/share/gnome/apps/Internet.

```

That is the only time that the word "gnome" appears in the ebuild directory for firefox, in a Changelog. "gnome" doesn't appear in any of the firefox ebuilds. So, I really doubt that your USE="-gnome" will have any influence at all in firefox.

 *Quote:*   

>  *Quote:*   No need to be a programmer, start by reading the ebuilds and man pages... 
> 
> True, but going through a tree of ebuilds isn't everyone's cup of tea.  Providing documentation would make things easier for most users.  I don't see why anyone objects to this.
> 
> 

 

Of course it would be nice, but most use flags reffer to options passed to the ./configure script before the compilation starts. Even those options in the ./configure script are usually not too well documented. It is hard enough to maintain ebuilds, do not ask to the ebuild maintainers to do a work that has not been done upstream by the application's developers. Sometimes you can find some info about added/changed/removed use flags in the Changelogs that can be enlightening, though.

 *Quote:*   

>  *Quote:*   Right. To choose to compile an application with qt (the KDE toolkit) or gtk (the gnome/xfce toolkit) is not as simple as just wishing it. To use gtk in a program you actually need to program it in gtk. There is no way that a gtk program can be compiled for qt, or vice-versa. You can't choose this in gentoo nor in any other OS. 
> 
> You can choose this if programmers develop cross-platform applications.
> 
> 

 

Of course, which happens 1% or less of the times.

[edit]

and this would not be cross-platform, but cross-toolkit, there would be no problem using the program in any platform as long as it contains no platform specific code and the toolkit used to build it is available in the target platform

[/edit]

 *Quote:*   

>  *Quote:*   If a program uses a library or toolkit, you just can't compile it without that toolkit. That is why the kde programs do not have a qt use flag: they just need qt, it is out of the question, it is not an optional thing. 
> 
> Right, but if I'm running gnome and no kde programs, I shouldn't need any qt or kde libs.  Ditto for running kde and no specific gnome progs.

 

Sure, that is not a thing for discussion, but a reality. If a given program needs something, it will be pulled anyway, regardless of your use flags. Gentoo will not push anything that is not needed. If it eventually does, this should be reported as a bug, preferably with a patched ebuild attached.

The problem is that in binary distros, as every single feature is compiled in, all the applications need to install ALL their dependencies (because they all are compiled and linked in the main executable file, and not doing so would leave you with a broken system).

----------

## termite

 *Quote:*   

> Weird. Note that the firefox ebuilds DO NOT HAVE a gnome use flag. You can check yourself: 

 

Wrong!  Try 

```
eix mozilla-firefox
```

The ebuild inherits mozconfig-2, which has a gnome use flag.

 *Quote:*   

> Of course, if you don't need that, you can turn it on via use flag, if one use flag is available for that in that concrete program.

 

Which is why Gentoo is great.  I can turn stuff on and off.  But if I have no idea what the flag does specifically, I have no idea what it will do, so the only choice I have is to recompile and see.  In the case of things like FF, vlc, etc, that takes lots of time, which is why documentation would be nice.

----------

## i92guboj

 *termite wrote:*   

>  *Quote:*   Weird. Note that the firefox ebuilds DO NOT HAVE a gnome use flag. You can check yourself:  
> 
> Wrong!  Try 
> 
> ```
> ...

 

I didn't notice the eclass, sorry.

The only thing it does about the gnome stuff is this:

```

        if ! use gnome; then                         

                mozconfig_annotate -gnome --disable-gnomevfs

                mozconfig_annotate -gnome --disable-gnomeui

        fi

```

Whatever that means. Probably, it is a matter of googling a bit or diving into the firefox sources. Ideally, your idea is nice: to have a better documented use flags. But in practice, it is a huge amount of work to explain what every single use flag does on every package.

By looking at the disabled components, we can only make some assumptions. I would say that this is disabling some visual integration with gnome and probably some punctual handling of devices for some obscure purpose. I don't use firefox nor know all its capabilities, so I can't imagine something more concrete.

----------

## termite

It would be lots more work, yes.  So I want to figure out how us mortal users can help.  I googled the two mozconfig flags and found very little, even on the mozilla build config pages:

 *Quote:*   

> --disable-gnomevfs      Disable GnomeVFS support
> 
> --disable-gnomeui      Disable libgnomeui support (default: auto, optional at runtime)

 

VFS is some file system abstraction and gnomeui is something to do with the gnomeui.  This is exactly why we need documentation, so that as a user, I can disable the gnome flag if I like without fear that it will blow up FF.

So, if anyone can explain what on earth the gnomevfs and gnomeui libraries actually do and why the Mozilla people use them (optionally), that would be a good start...

----------

## i92guboj

 *termite wrote:*   

> It would be lots more work, yes.  So I want to figure out how us mortal users can help.  I googled the two mozconfig flags and found very little, even on the mozilla build config pages:
> 
>  *Quote:*   --disable-gnomevfs      Disable GnomeVFS support
> 
> --disable-gnomeui      Disable libgnomeui support (default: auto, optional at runtime) 
> ...

 

That is exactly the whole point. The maintainer of the firefox ebuild probably faces the same problem when s/he goes searching for info about this. Since the flags are not documented upstream, at least, not in an useful way. 

gnomevfs is the foundation of the Gnome Virtual Filesystem, and it is a way to abstract the hardware devices from the usual way that linux handles them. In kde you have a kio-slave for that, to the final user, they both are comparable. Note that it has not to be directly a firefox thing. Maybe this just activates a plugin or a complement for firefox or something like that. At a first glance I can't see why firefox needs such a thing so maybe we need to look into additional stuff it will be installing. As I said, I am not a firefox user so I don't really know.

This is the same for every single packages. Imagine the total amount of work to document something that is totally undocumented from upstream.

It is a bit easier to find possible answers to the libgnomeui integration. It might just be something related to the fonts, icons or something like that. Maybe... Don't trust a single work of what I say, since I haven't looked at the sources and don't plan to.

----------

## termite

I think we're arguing the same point here.  We both agree that more documentation would be useful and we both agree that it would be a huge amount of work.  

What I'm saying in addition is that Gentoo is this wonderful OSS community, and since members of that community are willing to contribute if they can, there should be tools for them to be able to do so.  One of those tools should be a space for better documentation of USE flags.  

A good place to start would be with the major packages (such as the mozilla suite, the major media players, etc).  There could be a team assigned to badgering the upstream developers to write one sentence about each of their config options (or point to where they're documented) and the team could collate these and put them up somewhere.

This would be a useful resource not only to the Gentoo community, but to the wider OSS community as well.

----------

## i92guboj

 *termite wrote:*   

> I think we're arguing the same point here.  We both agree that more documentation would be useful and we both agree that it would be a huge amount of work.  
> 
> What I'm saying in addition is that Gentoo is this wonderful OSS community, and since members of that community are willing to contribute if they can, there should be tools for them to be able to do so.  One of those tools should be a space for better documentation of USE flags.  
> 
> A good place to start would be with the major packages (such as the mozilla suite, the major media players, etc).  There could be a team assigned to badgering the upstream developers to write one sentence about each of their config options (or point to where they're documented) and the team could collate these and put them up somewhere.
> ...

 

Agreed.   :Very Happy: 

----------

## i92guboj

Look here:

http://www.squarefree.com/burningedge/releases/0.9.html

It seems that firefox uses gnome-vfs to access smb:// and sftp://, that changelog is from 0.9, so, nowadays, it might be used for more things. But that is a start.

----------

## termite

Seems it was similar at least up to 1.5: http://packages.ubuntu.com/dapper/web/firefox-gnome-support

That illustrates an earlier point I made.  Why did the FF developers decide to put in gnome support for smb and sftp, but not use the equivalent kioslaves interfaces for KDE?  And what about XFCE users? Hmpf!

----------

## mope

Don't know if this will help answer your question, but here are the two emerge outputs with and without USE=gnome for FF:

 *Quote:*   

> 
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies  ..... ....... done!
> ...

 

You might try starting with "-*" and building up from there, rather than taking flags away.

In the end though, you're not saving very much space at all. Even here the difference is what, 16MB?

But this is from my server so you probably already have a bunch of that stuff on your computer already that would make the savings even smaller.

I used to be opposed to kde *and* gnome libs on my computer  :Very Happy: 

But then I realized the goodness of K3B!

Be thankful you started recently...it wasn't until recently that KDE and gnome became modular and you really *did* have to emerge the whole of gnome or KDE  :Wink: 

----------

## i92guboj

 *termite wrote:*   

> Seems it was similar at least up to 1.5: http://packages.ubuntu.com/dapper/web/firefox-gnome-support
> 
> That illustrates an earlier point I made.  Why did the FF developers decide to put in gnome support for smb and sftp, but not use the equivalent kioslaves interfaces for KDE?  And what about XFCE users? Hmpf!

 

It is impossible to please everyone, so, they just developed based on the toolkit in which they were more familiar/comfortable, which seems to be gtk (though gtk is not properly a gtk application, but that is for another thread). XFCE don't has this kind of features (I think), and if it has or there are plans to include in into thunar or wherever, it will also be through gnome-vfs, I bet (after all, xfce is a child of gtk, just like gnome, and has much in common with it).

We could continue the list with the rest of toolkits: tk fltk, fox... And remember that firefox doesn't run just in linux. To add native support for every desktop/OS, would be also a very big effort. Sometimes, programmers have to stop at one point, because trying to expand the project too much would only lead to a very low quality product. After all, they are just regular humans, even if sometimes it doesn't seem so.

----------

## mv

The whole "experiment" is rather useless, since you can have this much easier without recompiling anything:

Assuming that your system is "current" (i.e. 

```
emerge -NpDu world
```

 will currently not change anything and 

```
emerge -eDp world
```

 shows exactly the packages which you have installed), you can just choose your useflags and then call 

```
emerge -eDp world
```

Then compare the output with the previous call of that command, and you know what can go (a script to sort and compare the listed packages comes in handy, here). The only thing which might go wrong is if you have really have run into a dependency bug in an ebuild, but these things are not so frequent.

Of course, the above approach is only useful to find out which USE-flags you want. Once you have decided, you must of course recompile with 

```
emerge -NaDu world
```

 to avoid breakage. Another misunderstandings:

 *termite wrote:*   

> How many (if any) libraries 
> 
> ```
> revdep-rebuild -av
> ```
> ...

 

revdep-rebuild only recompiles some packages (if they used a [deleted or upgraded] library) - it will not restore any of these libraries. If the packages should not be able to compile without these libraries, this is a depedency bug in the ebuild which should not occur. (However, even if it occurs, revdep-rebuild will not restore the missing library - instead, it will break with an error during the re-emerge in such a situation.)

But, as mentioned above, these dependency bugs are not very frequent.

----------

## termite

The point was to see what flags could be removed without losing functionality.  I should rephrase the original post, I suppose.

----------

## mv

 *termite wrote:*   

> The point was to see what flags could be removed without losing functionality.

 

You will always loose functionality, otherwise the USE-flag would not be there. It only depends on whether one considers this functionality crucial or not. As a typical example, the earlier mentioned berkdb USE-flag in subversion will allow you to store your repository in another format. So without this USE-flag you will not have this option. But if you did not use that repository format anyway (IIRC another format is the default) and do not access other people's repository, you will not miss anything. But nevertheless, there is a loss in functionality...

Of course, documenting very detailed the effect of each useflags for each package is a different story...

----------

## termite

Losing functionality is a relative thing.  Yes, I lost theoretical functionality by disabling the gnome flag on FF, but practically, I lost none, since I don't use those features.

----------

## mope

 *termite wrote:*   

> Losing functionality is a relative thing.  Yes, I lost theoretical functionality by disabling the gnome flag on FF, but practically, I lost none, since I don't use those features.

 

s/b

 *Quote:*   

> , since I havn't used those features, yet.

 

Or, even more accurately, how can you know what  you've lost and whether you need it if you don't even know what "it" is?  :Smile: 

----------

## fallen

I think that http://gentoo-portage.com/ will help you on your quest.

You can look up use flags and see what they're for, and what packages use each one.

----------

## mope

 *fallen wrote:*   

> I think that http://gentoo-portage.com/ will help you on your quest.
> 
> You can look up use flags and see what they're for, and what packages use each one.

 

These will be USEful, as well  :Wink: 

```

#grep -i 'useflag' /usr/portage/profiles/use.desc

#grep -i 'useflag' /usr/portage/profiles/use.local.desc

```

----------

## termite

Yes, I'm aware that there are USE flag descriptions.  My point was that most of them don't really tell you much.

----------

## fallen

yeah, you're right, i often wish there was more to it.

----------

## steveL

 *mv wrote:*   

> The whole "experiment" is rather useless, since you can have this much easier without recompiling anything:

 

That's a bit harsh isn't it? If it weren't useful to the OP s/he wouldn't have posted. Why not just say there's an easier way? And BTW you don't need a script to compare the files: 'man comm'.

 *mv wrote:*   

> Another misunderstandings:
> 
>  *termite wrote:*   How many (if any) libraries 
> 
> ```
> ...

 

Er that's not true. If the lib is a dep of the package, portage will install it when revdep asks it to remerge the broken package. (Adding -o to the call to revdep-rebuild will just build the deps of packages and not the packages themselves btw.) If it isn't a dep it's a bug in the ebuild.

Edit:

 *Quote:*   

> 
> 
> ```
> 
> #grep -i 'useflag' /usr/portage/profiles/use.desc
> ...

 

Just use euse -i <flag> (in gentoolkit)

----------

## mv

 *steveL wrote:*   

>  *mv wrote:*   The whole "experiment" is rather useless, since you can have this much easier without recompiling anything: 
> 
> That's a bit harsh isn't it? If it weren't useful to the OP s/he wouldn't have posted.

 

Yes, sorry. It didn't seem so harsh to me when I was typing it... my main intention was to prevent people from wasting time for things that can be done easier.

 *Quote:*   

> And BTW you don't need a script to compare the files: 'man comm'.

 

"comm" is only useful in this case if the files are sorted (by package names) - so you first have to extract the names and then sort. Yes, this can be a one-liner, but nevertheless a script for this one-liner is useful, because it is frequently needed (at least, I use it frequently).

 *Quote:*   

>  *mv wrote:*   revdep-rebuild only recompiles some packages (if they used a [deleted or upgraded] library) - it will not restore any of these libraries. 
> 
> Er that's not true. If the lib is a dep of the package, portage will install it when revdep asks it to remerge the broken package.

 

In this generality, you are correct. But we were speaking about libraries which were deleted by --depclean (after removal of some USE-flags), i.e. they have vanished because they are not anymore a dep of the package (unless --depclean were buggy, of course).

 *Quote:*   

> Just use euse -i <flag> (in gentoolkit)

 

To add another very useful one: ufed.

However, the description is often not correct or at least misleading. For example, on the texlive ebuild you actually save space if you select  things like zlib,t1lib,png (provided you have these libs installed anywa), because this will cause the installed libs to be used instead of compiling in a copy. You can only understand after reading the ebuild (and sometimes not even then) whether the flag is such an "use system library"-flag or whether it provides new functionality which requires the library.

----------

## termite

 *Quote:*   

> You can only understand after reading the ebuild (and sometimes not even then) whether the flag is such an "use system library"-flag or whether it provides new functionality which requires the library.

 

And therein lies my point!  How can anyone expect users to be able to select optimal (or even near-optimal) flags for themselves if they need to dig through a pile a ebuilds the size of China to do so, and even then can't be sure they know much more?

Better flag documentation is sorely needed...

----------

## steveL

 *mv wrote:*   

>  *Quote:*   And BTW you don't need a script to compare the files: 'man comm'. 
> 
> "comm" is only useful in this case if the files are sorted (by package names) - so you first have to extract the names and then sort. Yes, this can be a one-liner, but nevertheless a script for this one-liner is useful, because it is frequently needed (at least, I use it frequently).

 

You do? OK we'll add it to update then; you basically want to be able to change use flags and see the effect on world, right? Please tell me anything else you'd like in that regard on that thread.

 *Quote:*   

>  *Quote:*   Er that's not true. If the lib is a dep of the package, portage will install it when revdep asks it to remerge the broken package. 
> 
> In this generality, you are correct. But we were speaking about libraries which were deleted by --depclean (after removal of some USE-flags), i.e. they have vanished because they are not anymore a dep of the package (unless --depclean were buggy, of course).

 

Ah sorry, my bad, I am a bit burnt-out so I didn't read the thread properly. If that's happening, then it's most likely a bug in the ebuild for --depclean to think that the library is not a dependency. In any event it is a bug and needs to be reported.

I really recommend running the unstable version of portage btw (and not your whole system ofc ;)

 *Quote:*   

> To add another very useful one: ufed.
> 
> However, the description is often not correct or at least misleading. For example, on the texlive ebuild you actually save space if you select  things like zlib,t1lib,png (provided you have these libs installed anywa), because this will cause the installed libs to be used instead of compiling in a copy. You can only understand after reading the ebuild (and sometimes not even then) whether the flag is such an "use system library"-flag or whether it provides new functionality which requires the library.

 

Yeah you're right about the use flag descriptions. Personally I'd make it compulsory to describe how the USE flag you're adding to an ebuild changes it. Yeah it's more metadata but it's useful.

----------

## termite

 *Quote:*   

> Yeah you're right about the use flag descriptions. Personally I'd make it compulsory to describe how the USE flag you're adding to an ebuild changes it. Yeah it's more metadata but it's useful.

 

Absolutely!  How can we campaign for this sort of thing? (or, how can we help, as mere mortal users?)

----------

## mv

 *steveL wrote:*   

>  *mv wrote:*    *Quote:*   And BTW you don't need a script to compare the files: 'man comm'. 
> 
> "comm" is only useful in this case if the files are sorted (by package names) - so you first have to extract the names and then sort. Yes, this can be a one-liner, but nevertheless a script for this one-liner is useful, because it is frequently needed (at least, I use it frequently). 
> 
> You do? OK we'll add it to update then; you basically want to be able to change use flags and see the effect on world, right?

 

No. Although this is off-topic, I usually do not use it to see the effect of useflag changes (although this also happens occasionally) but mainly to see whether everything is clean, i.e. whether an emerge -peD world shows exactly my installed packages and versions - then I usually unmerge the installed packages/slots not shown. In other words, I use it like a rigorous --depclean (originally, I had thought that this is equivalent to --depclean, but sometimes depclean is more careful and does not show all of these packages, in particular in connection with slots).

----------

## synss

I have not read the whole thread I must say, but it is more or less written in the manual section 6.b how you can chose KDE

USE="-gtk -gnome qt3 qt4 kde"

however, removing things like the berkeley DB is probably a very bad idea... Either the program will use a self-implemented DB, which may not be as good as the berkeley one or no DB at all and therefore will run slower. Secondly, the berkeley DB is very small and you won't gain anything by removing it.

----------

## mv

 *synss wrote:*   

> however, removing things like the berkeley DB is probably a very bad idea... Either the program will use a self-implemented DB, which may not be as good as the berkeley one or no DB at all[...]

 

I would not claim this in this generality. On my machine, for example, the berkdb useflag is only used by very few packages:

 python and perl (and its libs). Here it is probably only needed to build a python/perl interface to these libs. You will probably need this only if you program in perl/python (I cannot imagine that otherwise you will have installed packages needing this interface).

 subversion. This is the example I had mentioned earlier. Unless you have old svn repositories, you will not need it or profit from it.

 apr-util. No idea why it is needed here. Actually, I do not even know what apr-util is good for if you do not run apache, but it is a dependency of some packages.   :Confused: 

 gdbm: I have no idea why a database has another database as an optional dependency. Looking at the ebuild and the configure script, it seems that just the berkdb is being linked when the useflag is set without having any other influence on the code. Very strange...   :Confused:  

It seems that I could live with USE='-berkdb' as well, weren't it for some packages for which the dependency on berkley DB is non-optional.[/list]

----------

