On Jun 26, 2007, at 20:55, Brian Campbell wrote:

Is there any semblance of an up-to-date MacPorts manual? If not, where should someone new go to find out how to create or update a Portfile?

Specifically, I would like to upgrade a package to the latest version, which is not yet in the latest official Portfile. I tried copying the portfile out into a new working directory, and running "port -dv checksum" (trying to vaguely follow along with the old DarwinPorts manual, from the Wayback Machine), but I get a permission error as it's trying to create a directory in the /opt/ local hierarchy. I'd rather not run commands with root permissions while I'm still experimenting with an undocumented system, so I'm wondering how I can tell port to just do everything in the current directory (or some other given directory), rather than /opt/local.

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.

I then tried creating ~/.portsrc and ~/.macports/ports.conf (as port (1) and ports.conf(5) disagree on where the configuration file should go), containing settings for both prefix and portdbpath, but neither of these actually affected where port was trying to work; it kept trying to create a directory in /opt/local/var/db/dports.

I thought the prefix was set at install time. I'm not that familiar with what the manpages say.

So, is there any way to actually build a port without doing it in the /opt/local hierarchy? Or is there any documentation, or anywhere I can find out about what the expected way to develop under MacPorts is?

You've already found the old documentation in the Wayback Machine. That's all there is. Well, and what's in the current wiki. If you're looking for help understanding portfile syntax, it's instructive to look at existing ports. It may also help to subscribe to the commit emails so you see what kinds of changes people are making to the ports. Also subscribe to the dev list, where discussion sometimes occurs about specific commits, when people have comments or questions about them.

$ port version Version: 1.442

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 http://geeklair.net/ 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. Regards,... -jmpp

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

Thanks! I think I understand a little better now. Now I need to figure out what the best way is to document in the manual, since I'm trying to document everything I need to do there so people don't have to ask these questions in the future. On Jun 30, 2007, at 2:38 AM, Ryan Schmidt wrote:

I've never had to blow away /opt/local and start over. I use sudo for most port commands, because they complain about permissions if I don't. I could chown various directories but so far I haven't bothered.

I've had to, and that was just from doing normal installation and upgrading of existing packages. I might have been able to recover it, but because of the lack of documentation, I really didn't know how to go about doing that. My next task will be to figure out and document how all of the indexes, receipts, and build directories work, and document that, so people who are trying to figure out what's breaking will know what they're doing in the future.