MacPorts manual, or info on MacPorts development
Juan Manuel Palacios
jmpp at macports.org
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 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
More information about the macports-users
mailing list