Alan McKinnon wrote:
On Sun, 2 Oct 2011 10:53:46 -0400
Michael Mol<mike...@gmail.com> wrote:
On Sun, Oct 2, 2011 at 7:58 AM, Alan McKinnon
<alan.mckin...@gmail.com> wrote:
On Sun, 02 Oct 2011 06:36:54 -0500
Dale<rdalek1...@gmail.com> wrote:
Alan McKinnon wrote:
On Sun, 02 Oct 2011 05:13:49 -0500
Dale<rdalek1...@gmail.com> wrote:
You often mention the attraction of Gentoo is you get only what you
want. But, consider this; if you put flags routinely in make.conf
you lose most of that benefit. You end up with the equivalent of
Mandrake where you complied it yourself, not the binary distro.
USE="<every possible flag enabled>" emerge something and
yum install something and pretty much equivalent in terms of end
result.
I'm actually very much in Dale's usage pattern here. If there's a
feature I want, and it's a globally-valid USE flag (such as, say,
ipv6), I put it in make.conf. If there's a feature I want, and it's
package-specific, it goes in package.use. If there's a feature I want,
it's a globally-valid USE flag, but I *don't* want it in a particular
package (say, X in vim), the enabler goes in make.conf, the disabler
goes in packages.use; for 90% of packages, I want that support.
So that's not USE=<every possible flag enable>, that's USE=<all the
global flags I want enabled>.
As with all things in life, USE flags require intelligence, common
sense and familiarity to use to best advantage. Not all global USE
flags are equal or used in the same way!
USE="ipv6" is mostly global and single-meaning. ipv6 support means
just that - ipv6 support. For a daemon, that would be listen on an
ipv6 interface and talk it back. For config tools, it's " set up
interfaces and routes ipv6 style". It's hard to come up with a meaning
for the flag that's outside that narrow range; it's equally hard to
come up with a reason to use in package.use. Maybe disable it for a
package that supports ipv6 but is known to be broken in it's support.
USE="perl python" is a very different kettle of fish. While also
global (i.e. used in a similar way by more than x number of ebuilds),
the meaning in use can differ wildly. It can mean to build support
for extra tools written in perl|python, or build language bindings, or
use language bindings and possibly many things. These flags can benefit
from being used in package.use - whereas you probably want ipv6 support
everywhere if used, perl|python isn't used the same way.
Your post indicates you already know this :-)
I mentioned it to Dale to illuminate that just because a flag is
*defined* globally doesn't mean you have to *use* it globally. And the
reverse is also true - overlays often have flags used in many ebuilds,
always with the same meaning (e17 is like this), but are not global in
use.desc. My own make.conf has many of these flags.
Sometimes I wish Gentoo would express these distinctions. Then I think
about what it would take to do that, and shelf the idea :-)
--
Alan McKinnnon
alan.mckin...@gmail.com
I saw your point. That's why I said I do make exceptions. For me, I do
whatever is easier to keep up with. I actually went back and removed
perl and python from make.conf so that it would basically go by the
ebuild I guess. When I ran emerge -uvaDN world, it wanted to rebuild
actually nothing. I guess I could do -perl and -python to force it to
disable but that may cause some other issue that I'm not wanting to deal
with. So, I ended up with perl and python removed from make.conf. When
the changes you were talking about come along, I'll know it and can see
what I need to do to get what I need.
One thing I don't like about having all the separate file in package.*
is trying to keep up with them. I have several files that are there
that don't even have anything in them because either portages unmask
feature or autounmask created them. I sort of wonder if it wouldn't be
easier for me to go back to a single file. Then I can open it with
kwrite and if the file has a lot in it, just use the find tool. I know,
I'm sure there is some command that can do that but that's another
story. Of course I also have several files that do have something in
them. Thing is, if I suspect something is in a file and want to look, I
have to open each file, look to see if it's there and if not, repeat
with the next one until I find it. Sometimes that is like a needle in a
haystack.
One step forward, two steps back. :/
Dale
:-) :-)
