Hi Juan,
On Apr 17, 2007, at 10:33 AM, Juan Manuel Palacios wrote:
On Apr 17, 2007, at 11:59 AM, James Berry wrote:
I intentionally kept the behavior the same as it was before. I
think there are arguments to both behaviors (overriding the whole
file vs overriding duplicate fields). Overall, the "only one file
wins" strategy is probably simplest to understand, and since we
don't have that many settings, probably not onerous for the user.
I actually came upon this issue again when I added the (hidden)
feature of parsing options from ~/.macports/user.conf. Should this
file be allowed to contain only per-user settings (such as
submitter name, submitter email, etc, for mpwa) or should it also
allow the ports.conf settings to be overridden? I decided on the
former, but once again there may be arguments to have _this_ be
the mechanism to allow per-setting overrides for the system
configuration settings. (For those curious, there are no settings
read from user.conf that currently do anything, but the idea is
that this will be a source of information about the current user,
used while submitting ports to mpwa, which isn't yet available.)
James
I think that if we allow overriding of conf values in a user
confined doc like ~/.macports/user.conf, we should go ahead and
allow selective overriding from existing conf files and dump the
current behavior (overriding duplicate fields --proposed behavior--
winning over overriding whole files --current behavior--, borrowing
from your wording). I am sure explaining to users they cannot
override system wide settings in ~/.macports/ports.conf but that
they actually can in ~/.macports/user.conf, while also explaining
that if they have ~/.macports/ports.conf they have to insure it is
self contained (that is, every single value for keys that mp needs
to function properly are in that file), will get pretty confusing.
Hell, I even had a hard time writing that just now! Not too sure it
makes any sense the way it came out ;-) But I'm sure you follow me.
What I propose:
-) File precedence: ${prefix}/etc/ports/ports.conf (note, we should
update that to ${prefix}/etc/MacPorts for consistency's sake while
at it!), ~/.macports/ports.conf, env PORTSRC variable (or however
it's called). Last one found wins;
-) A value found in file 2 overrides the same value found in file
1, and the same in file 3 overrides the one in file 2, etc (only
values, not entire files);
-) ~/.macports/user.conf is kept solely for user information with
respect to mpwa;
-) Maybe we could also include support for ~/.macports/
variants.conf and also, why not, an env variable for it;
-) How about also an equivalent env variable for ~/.macports/
user.conf? Consistency is a big plus!
Thoughts?
My thought is that it works fine right now. It's not my top priority
to beat this very minor piece of functionality to death. My original
mail was just to make sure I let people know that I changed the name/
location of a file that nobody probably uses. It was not an attempt
to spend a bunch of time and energy to rethink preferences ;)
James
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
