Undocumented ports.conf options

Paul Guyot pguyot at kallisys.net
Tue Feb 20 00:07:32 PST 2007


On Feb 20, 2007, at 16:52, Juan Manuel Palacios wrote:

> 	Finding out which "options" are up for user interaction (and  
> therefore documentable) and which aren't was also one of my  
> explicit goals; comments like yours, "stay away from those!", is  
> what I was looking for with my mail. I didn't get all of them from  
> a standard ports.conf file, I was reading into the  
> bootstrap_options variable that gets initialized in dportinit in  
> base/src/darwinports1.0/darwinports.tcl.
>
> 	So help me here build the final list. "Options" that are not meant  
> for user interaction and therefore should *not* be documented are:
>
> -) xcodeversion
> -) xcodebuildcmd
> -) porttrace
> -) portverbose (why would you keep this one from being user  
> customizable?)

Please do not touch those.

> -) libpath? (from reading dportinit, it seems to me like this is a  
> dangerous one, but you didn't say anything about it)

libpath is simply ${prefix}/share/darwinports/Tcl/
This one could be documented, but I have yet to understand the  
interest of changing the default value.

> -) auto_path? (likewise)

auto_path is a standard Tcl variable, documented in library(n). MP  
code just plays with it, in particular to append libpath to it.

> -) master_site_local (created by jkh in r5004, reportedly as a  
> customizable option meant to "(...) allows portfetch.tcl to go  
> first to a local distfiles cache, if available, before going out  
> over the net to try and get it by less efficient means.", but  
> reading base/src/darwinports1.0/darwinports.tcl around line 450 and  
> base/src/port1.0/portfetch.tcl around line 190 doesn't tell me much  
> what the option does and how I could document it)

This one works like the MASTER_SITE_LOCAL environment variable, and  
in fact is set to this value during runtime. The value is appended to  
the list of mirrors before doing a fetch. Jordan might have used this  
feature at some point, it corresponds to very specific scenarios  
where you deploy MacPorts on several machines and you host the  
distfiles somewhere on your local network, for example by sharing a  
flat version of /opt/local/var/db/dports/distfiles/.
I am wondering if anyone (except maybe Jordan) is using that today  
and might be interested in using it. It still means having a good  
idea of what is going on in the fetch phase and how to flatten the  
distributed files. The behavior could be broken with some rewrite of  
the fetch code that would help us having mirrors, and I would  
personally not care about maintaining this feature. In a nutshell, I  
would not document it.

Paul




More information about the macports-dev mailing list