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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
