MacPorts manual, or info on MacPorts development

Brian Campbell lambda at
Thu Jun 28 11:27:05 PDT 2007

On Jun 28, 2007, at 12:24 PM, Juan Manuel Palacios wrote:

> 	Usually when testing out a port, you only need sudo when  
> destrooting and installing either 'cause you need to set special  
> permissions on files or because you need write to otherwise off- 
> limits directories. Everything else from fetching up to build does  
> not require higher powers for anything in particular, so I'd say  
> that whatever gets you write access to the directories where those  
> actions take place (distfiles and build) is just as good (chown,  
> chmod,...), making it clear that the software directory need not be  
> touched (and receipts too, just to be safe).

I also needed permission to just download the file to the distfiles  
directory, and I would like to be able to destroot without worrying  
about accidentally messing anything up (isn't that the point of  
destrooting? so you can make sure things work in a sandbox before  
really installing them?)

> 	You can still install MacPorts anywhere you prefer, that still  
> hasn't changed... but regardless of where you install it you'll  
> still need sudo for certain actions (like, some ports need to set  
> special permissions on the files they install). The recommended way  
> to do development is just what makes it easier for you, what best  
> adapts to your particular practices while not providing cover for  
> potential bugs that users who do need to go through sudo might  
> encounter. It may feel like I'm being a little vague here, but I  
> seriously doubt there is *one* way we could recommend, there are so  
> many to test ports that work equally well, give or take...

Sorry, I should have asked a few more specific questions.

If I install directly from Subversion, will it automatically (as the  
manual implies) use the Subversion dports tree (or mports tree, as of  
the name migration) in sources.conf.

Also, if you install from Subversion, will the distfiles and build  
directories be in the /opt/local tree, or will they be somewhere in  
the Subversion checkout tree?

Finally, is it possible to switch an installation from the binary  
install to one based on Subversion, so you can hack on the latest  
code without having to blow away your /opt/local and start over?

I guess on the "one best way" thing, what I'd like is one reasonably  
good way that we can document in the manual, and that will work for  
people who have started out from installing a regular binary install  
or a SVN install and don't want to mess up their whole /opt/local  
tree. In most projects, what you do to develop is just check out of  
CVS/SVN/whatever, do whatever autoconf/configure/make dance you need  
to build the project, and then you can test everything from your  
build directory before you do a make install. For something like  
DarwinPorts, though, you need to be mucking with your actual  
installation, which when you depend on it and don't want to have to  
reinstall from scratch, can be a little scary.

> 	Do not let me stop you if you feel you can contribute patches to  
> our man pages too!

Again, the main issue here is that I don't yet know exactly what's  
going on. Which file is correct about where the user configuration  
file goes, port(1) or ports.conf(5)? And what configuration options  
are respected at what times? I can start trolling through the code to  
figure these out, but it might make more sense for someone with more  
experience to just tell me (and then I'll document it), or fix the  
documentation themselves.

> 	I appreciate your work on the guide! We're finally reviving that  
> effort and already automated its nightly regen at http:// 
>, content that you and others submit  
> will be reflected there after a 24 hours wait at maximum. I'm  
> coordinating with MacOSForge admin personnel moving this to our  
> official website.

Great, looks good. Thanks for taking the lead on getting usable  
documentation up again.

More information about the macports-users mailing list