MacPorts manual, or info on MacPorts development

Emmanuel Hainry ehainry at free.fr
Thu Jun 28 09:43:40 PDT 2007


Citando Brian Campbell :
>  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?

Yep, chmod on the build, distfile and package directories is how I am
running macports. Then port archive works for most ports, but it stops
anytime it enters the install phase of a dependency, requiring me to
sudo install then retry. Some ports however require root privileges for
destroot either because they want to create a user or they try to chown
some files or put setuid bits, those kind of things.

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

Then maybe port selfupdate does not require root (I have also chmodded
the source directory to be able to port sync without being root, but
each sudo port selfupdate, steals some rights...), which is a concern as
my first goal was to avoid fetching and extracting as root.

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

Then 'man portfile' is here: it's clearly official, it is up-to-date
enough, it contains examples for better understanding, you must read it.
For what goes where, there is 'man porthier' (not as up-to-date, but
however informative). You can also read 'man portstyle', it is short and
largely not applied (indentation rules for example) but contains
answers.

And the "exampleport"
~dp/sources/rsync.rsync.darwinports.org_dpupdate1/base/doc/exampleport/Portfile


Good reading, I hope you will write beautiful portfiles :)

Emmanuel



More information about the macports-users mailing list