| 1 |
Peter <pete4abw@×××××××.net> posted |
| 2 |
pan.2006.06.14.15.29.03.897668@×××××××.net, excerpted below, on Wed, 14 |
| 3 |
Jun 2006 11:29:06 -0400: |
| 4 |
|
| 5 |
> The use.default file in default-linux is now empty. The one in base gives |
| 6 |
> you nothing to compare it against. Was there another file you meant? |
| 7 |
|
| 8 |
You don't /need/ another file to compare it against. That you seem to |
| 9 |
think you do implies you don't quite understand how the thing worked, |
| 10 |
which explains why you don't see the problem with it. |
| 11 |
|
| 12 |
use.defaults consists of a list of pairs of (normally unset, therefore off) |
| 13 |
USE flags and packages. If the corresponding package is merged and |
| 14 |
defaults is in the USE.ORDER list, the flag will now default to on instead |
| 15 |
of off. (As it is normally last in the USE.ORDER list, specific settings |
| 16 |
higher in the list, including those made by the user, will of course |
| 17 |
override this, as one might expect.) |
| 18 |
|
| 19 |
Thus, you don't need another file to compare use.defaults against, as if |
| 20 |
the package triggering the USE flag is merged, the default is on, while if |
| 21 |
it's not, the default is off. Thus, there is no other file to compare it |
| 22 |
against, only the list of your merged packages. The use.defaults file(s) |
| 23 |
simply list the packages that trigger the USE flags. That's all. |
| 24 |
|
| 25 |
The problem with this approach is that the USE flags end up changing |
| 26 |
unexpectedly under a user's nose (sound familiar? understand why that's a |
| 27 |
problem? THOUGHT so!) based on what's merged. Note that USE flags are |
| 28 |
only for OPTIONAL dependencies. Thus, we have a scenario where a bunch of |
| 29 |
packages with OPTIONAL dependencies on something, thus with it as a USE |
| 30 |
flag, are merged, then something comes along with a NON-OPTIONAL |
| 31 |
dependency on the same package and merges it. Suddenly and without user |
| 32 |
intervention, the USE flag changes from OFF by default to ON by default, |
| 33 |
and all those previous packages merged with it off now show up in --newuse |
| 34 |
to be remerged! |
| 35 |
|
| 36 |
The most direct solution to the problem is to take defaults out of |
| 37 |
USE.ORDER, so use.defaults is no longer factored in. Altho there's going |
| 38 |
to be a bit of initial pain for users who hadn't examined their use flags |
| 39 |
(as I contend a responsible admin will have done), for new users and after |
| 40 |
the initial adjustment by old users, USE flags will now actually be |
| 41 |
normally deterministic -- they'll only change when a user changes them (or |
| 42 |
when a profile has reason to do so, and that happens only for a very good |
| 43 |
reason with existing profiles, so it would normally only happen when a |
| 44 |
user changed his profile). MUCH better, as the user doesn't have to worry |
| 45 |
about USE flags changing out from underneath him. Given your complaint |
| 46 |
about the changes you experienced, I think you'll agree that having them |
| 47 |
change out from underneath you isn't all that pleasant, so this is a |
| 48 |
needed change. The only problem was that it wasn't properly documented, |
| 49 |
but that has been taken care of now as well. |
| 50 |
|
| 51 |
|
| 52 |
|
| 53 |
-- |
| 54 |
Duncan - List replies preferred. No HTML msgs. |
| 55 |
"Every nonfree program has a lord, a master -- |
| 56 |
and if you use the program, he is your master." Richard Stallman |
| 57 |
|
| 58 |
-- |
| 59 |
gentoo-dev@g.o mailing list |
Archives