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:// 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.
Great, looks good. Thanks for taking the lead on getting usable documentation up again.