Thomas Sachau wrote:
> I dont mind, if a flag is really usefull and requested by a big majority of the users. But as Gentoo
> is about choice, the minority should be able to easily choose something else, e.g. by a less
> heavyweight profile. If a majority of mplayer users want to be able to play audio files, i dont mind
> to disable it for myself, if i dont want it. But on the other hand shouldnt a handfull of users be
> able to dictate the enabled and disabled USE flags for many other users, which might have a
> different interest.
>   

Just as a stake in the ground, but personally I have two modes of 
interest: a) for desktop use I just want a middle of the road profile 
which enables "useful stuff", and b) I have some embedded projects where 
every byte is precious


>> It would be nice if we actually documented why they were enabled.  Does the 
>> use flag enable significant functionality that would otherwise make the software 
>> less useful.
>>     
>
> Documentation is always usefull. One should also check the additional overhead of the USE flag.
>   

I often hear this general kind of commentary.  Just out of interest, 
how/why do you care about the byte count that much? Apart from embedded 
work, or perhaps virtualised servers, I find it surprising to imagine 
that "most people" find the "cost" of minimising installed size (well 
more than the obvious stuff)  to be worth the effort (in general)?

What kind of size of install do you run?  Sub 200MB? Sub 50MB?  How much 
"bloat" are you seeing by fiddling with changing your profile from defaults?

Personally I recently figured out how to create my own local profiles, 
and this allows me to control the main USE flags to my liking.  
Personally I find that minimising the number of interpreted languages 
installed (perl etc) and optimising locale size is by far the dominant 
factor in the size of the install.  Thereafter controlling whether 
mplayer also plays x264 files seems largely second order (at least on my 
install)?

If you are worried about security issues in dependencies then do also 
look at hardened (esp. with the gcc-4.4 hardened overlay) and perhaps 
grsecurity - this can very effectively mitigate the effects of many 
security holes.

Good luck

Ed W