Portfiles based off of Subversion trunk?

[Ryan Schmidt]

On Feb 3, 2011, at 08:50, Jon Hermansen wrote:

> Even though I'm sure I probably shouldn't do this, I did figure out how:
> 
> svn.revision        [exec svn info https://svn.example.com/foo/bar/baz | perl -n -e "if ( /^Last Changed Rev: (\\d+)$/ ) { print \$1 };"]

That's pretty clever, and in a way I like it. It might be useful in certain special applications, especially local port repositories. The problems I see with this, in ports for general consumption:

 * This requires the "svn" and "perl" commands to be available and functioning whenever the portfile is used for any purpose, including "port info", "portindex", "port clean", etc. "perl" is always a part of Mac OS X; that's not a problem. "svn" was not a part of Mac OS X until Leopard, so users on Tiger would have to first install the subversion port, or they would encounter an error. This is perhaps not a big deal as Tiger gets older and less relevant.
 * It also requires that repository to exist and be online and reachable (thus, for an Internet connection to exist) in order to do anything with the port. Certainly users would expect to need that if they're asking to install the port, but not necessarily when they're just asking to get info about it, or clean it, or index it. Executing a network connection every time the port is used for anything would slow down all port operations on this port.
 * It assumes that all versions of the upstream software into the future can be installed with no changes to the portfile. It's quite common for port maintainers to need to make minor tweaks to upstream software before it can be built in MacPorts. Maybe a patch needs to be applied. Maybe some files need to be moved.
 * It removes any remaining notions we may have had about port testing. Currently, ports are often broken because the maintainer did not test on the OS version or processor architecture the user has, or with the combination of other installed ports they have, or did not test all the variants. With your above proposal, there's no guarantee the maintainer has even tested a particular revision on even a single Mac. It would be nice to know, before I install a port, that at least one person somewhere has been successful in doing so before me. And that's really the purpose of having a port maintainer -- someone who tests the port, hopefully uses it himself -- one extra safeguard between the upstream developers and the MacPorts-using public. If a developer commits something incorrect, or worse, a hacker gains access to the repository and commits something malicious, we don't want that instantly broadcast to all MacPorts users. (I could make a similar argument about a hacker gaining access to the MacPorts repository, but for the purpose of this argument, I won't.) When I update a port, either on my own or using a patch someone supplied in a ticket, I at least verify the port builds on my system. I might not always check that the software runs, but at the very least, if there were a bug that caused the build to fail, or that did something malicious or even just unintentionally bad to my system (I recall a port once that inadvertently deleted /tmp during the build), then I wouldn't commit the update, and the problem would be limited to my system instead of affecting everyone.