Change in ports.conf and ~/.portsrc search paths

Juan Manuel Palacios jmpp at
Tue Apr 17 10:33:05 PDT 2007

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!



More information about the macports-dev mailing list