| 1 |
2009/9/30 Ed W <lists@××××××××××.com>: |
| 2 |
> Gordon Malm wrote: |
| 3 |
>> |
| 4 |
>> It is my estimation that flag was disabled by mistake on the |
| 5 |
>> hardened/linux/${arch} profiles. I have re-enabled it. Should be fixed on |
| 6 |
>> your next sync. |
| 7 |
>> |
| 8 |
>> |
| 9 |
> |
| 10 |
> |
| 11 |
> Quick question and slightly OT |
| 12 |
> |
| 13 |
> How do others setup their own "profile"? |
| 14 |
> |
| 15 |
> I'm thinking that I try to sync a base /etc/make.conf across quite a few |
| 16 |
> machines and whilst each machine slightly customises this, it would be |
| 17 |
> really nice to have a master set of USE defaults and package.use / |
| 18 |
> package.keywords options |
| 19 |
> |
| 20 |
> I presume one needs to simply setup the profile somewhere outside of the |
| 21 |
> /portage directory and then reference it? Any thing else needed other than |
| 22 |
> a "parent" file pointing back at the real base profile? |
| 23 |
> |
| 24 |
> Any other tips from others who do something like this? |
| 25 |
|
| 26 |
Personally, I believe that gentoo has suffered from global USE flag |
| 27 |
bloat for a long time. It is unfortunate that aligning the hardened |
| 28 |
profile with the (nowadays complex) de-facto profile stack brings that |
| 29 |
problem over into the hardened camp as a side effect. If I had a penny |
| 30 |
for every obscure bug, block and obtuse manifestation of breakage for |
| 31 |
which I have assisted users with that can be attributed to the system |
| 32 |
complexity and fragility that results, I would probably be happily in |
| 33 |
retirement by now. What's more, packages still make sadly limited and, |
| 34 |
at times, questionable use of the pkginternal feature (IUSE="+gtk" in |
| 35 |
net-analyzer/wireshark being an example that I find particularly |
| 36 |
grating). |
| 37 |
|
| 38 |
Essentially, I see it as an unholy mess and have long since given up |
| 39 |
hope that there will ever be anything resembling a coherent and |
| 40 |
carefully considered policy. So, being confident as to my preferences |
| 41 |
and wishing to keep this policy area under my direct control, I have |
| 42 |
long since eschewed the profile-sourced defaults. Here's an example of |
| 43 |
how I go about it from one of my servers: |
| 44 |
|
| 45 |
USE_ORDER="env:pkg:conf:pkginternal" |
| 46 |
USE_CORE="cracklib hardened nptl pam pic readline ncurses unicode urandom zlib" |
| 47 |
USE="${USE_CORE} mmx mmxext sse sse2 sse3 sse4.1 pcre" |
| 48 |
|
| 49 |
The trick here is to drop "profile" from USE_ORDER (it is there by |
| 50 |
default). The 'core' flags there are essentially a slightly reduced |
| 51 |
version of those defined in the now deprecated profile. Frankly, even |
| 52 |
these constitute too many global flags for my taste, but there are |
| 53 |
some there which - after much deliberation - I determined should |
| 54 |
remain. This has rather more to do with the manner in which certain |
| 55 |
ebuilds work and the assumptions made on the part of their developers |
| 56 |
rather than what I deem as being 'safe'. |
| 57 |
|
| 58 |
Aside from that, I employ package.use extensively and often use |
| 59 |
comments to make it perfectly clear as to why a given flag has been |
| 60 |
switched on or off. |
| 61 |
|
| 62 |
Regarding "nls", as someone who requires only English language |
| 63 |
support, I find it to be almost useless. I say almost because, while |
| 64 |
it is not necessarily required, I would say that it is a reasonable |
| 65 |
default for php (some php applications require it). Why php still |
| 66 |
fails to make use of pkginternal is something I continue to find |
| 67 |
baffling. |
| 68 |
|
| 69 |
Cheers, |
| 70 |
|
| 71 |
--Kerin |
Archives