MacPorts manual, or info on MacPorts development

Juan Manuel Palacios jmpp at
Thu Jun 28 09:24:56 PDT 2007

On Jun 28, 2007, at 11:11 AM, Brian Campbell wrote:

> On Jun 27, 2007, at 2:03 AM, Ryan Schmidt wrote:
>> I don't know of a way to do that. I think you have to use sudo,  
>> and it will do things in /opt/local.
> Is that what most MacPorts developers do? What happens when they  
> screw something up, and need to throw out their whole /opt/local  
> and need to try again? I was hoping for something a little safer.
> On #macports, jmpp suggest just chowning /opt/local/var/db/dports/ 
> build and /opt/local/var/db/dports/distfiles/* to my user, which  
> seems to work well enough, although it feels a bit skeevy. I guess  
> chmodding them to be group writeable would work too, as long as the  
> groups work out. Is this the best way to safely test ports, only  
> actually running sudo when I want to test port install?

	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).

	In short, the less sudo you use the better, of course, so if for any  
reason you are fearing the integrity of your MacPorts tree while  
testing something then I would certainly advice enabling write access  
to the distfiles and build directories, just like you said in your  
patch (which I already committed, by the way ;-).	Now, if something  
does go wrong while destrooting and installing (through sudo powers,  
terrible!), that's something we *need* to detect before feeding the  
port to our users... which is precisely what we have maintainers  
for ;-) In other words, sudo *will* be needed at some point and it's  
preferable for failures to occur, if at all, while on maintainers  
hands (which will presumably know how to get back on their feet  
quicker) than on users'.

> Looking at the manual, it appears that the reason I was confused is  
> that the manual installs MacPorts into ~/macports, so most of the  
> commands (other than ones like port install) can be run without  
> superuser permissions. Does this still work in the current version  
> of MacPorts? Is this the recommended way to do development?

	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...

>> I thought the prefix was set at install time. I'm not that  
>> familiar with what the manpages say.
> That appears to be the case. The man pages seem to be a bit unclear  
> on this; perhaps they could be edited to be more nearly correct?

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

>> You've already found the old documentation in the Wayback Machine.  
>> That's all there is. Well, and what's in the current wiki.
> There is also the doc/guide directory in SVN, which I'm actually  
> starting to submit patches to as I learn about MacPorts. The  
> problem is that I need to find out what the right way to do stuff  
> is before I can actually document it.

	I appreciate your work on the guide! We're finally reviving that  
effort and already automated its nightly regen at 
macports_guide/, 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.

>> If you're looking for help understanding portfile syntax, it's  
>> instructive to look at existing ports.
> It's not so much portfile syntax I'm interested in, it's best  
> development practices. Also, I would like for there to be an up-to- 
> date official manual, to make it easier for people to get started  
> creating or updating Portfiles.

	Our guide! ;-) That's where all this info and more should go.



More information about the macports-users mailing list