On 5/14/2011 12:01 PM, Indi wrote:
On Sat, May 14, 2011 at 05:53:56PM +0200, Alan McKinnon wrote:
Apparently, though unproven, at 16:37 on Saturday 14 May 2011, Indi did opine
thusly:
True, just be aware that if you enable gtk *globally* you will end up
building the gtk interface for absolutely everything which has that
option.
Far better (IMO, YMMV) is to use /etc/portage/package.use specify such
things per package. Unless, of course, you like having a gtk GUI for
everything.
:)
No, it is much better to enable such a flag globally and *disable* it using
package.use where you do *not* want it.
Personally, I have better things to do than examine every new or changed
package that shows up after avuND world and edit package.us for every single
flag in that huge list.
Sounds like the old "6 of one, a half-dozen of the other" to me...
What makes the subtractive method better?
Actually its more like the old "use whichever way makes
sense for the situation." :)
Its mostly a matter of probability. If I'm using a GNOME
desktop then I probably *do* want the GTK+ for any packages
that support it; the same argument goes for KDE and Qt.
Similarly, if my system is on a Windows AD domain, I
probably want samba, ldap, and kerberos support for any
utilities that have it. If I'm using bash completion
packages, I don't want to worry about which packages
do/don't have one, I just want them installed. These type of
flags have essentially the same effect on every package, and
as Alan said, there's no need to waste time checking if each
package does or doesn't support GTK individually if you're
always going to enable it anyway.
OTOH, I probably don't want to set a USE flag like 'extras'
or 'doc' globally. In those cases I'll turn it on when
needed. Similarly, USE flags that only applies to one
package (like "net-print/hplip snmp scanner hpcups
new-hpcups hpijs") don't make sense globally, so they are
best left to package.use.
--Mike
