On Oct 27, 2007, at 12:13, paul beard wrote:
On 10/26/07, Ryan Schmidt wrote:
No port (and no other non-Apple software) should ever install
anything under /System!!!! The port needs to be revised to install
not in /System/Library but in /Library, and the name of the plist
should begin with org.macports not org.freedesktop. I don't see
anything in the portfile that causes this, so it must be the
project's own Makefile. In this case, a patch will need to be written
to change the name of the file. In addition, the authors of the avahi
should be notified to never install anything under /System. Someone
should file a Trac bug on this and assign and Cc it to the port's
maintainer.
in v1.6 would a sanity check to port, akin to the "dry run" command
I see in various utilities, make sense? Right now we have "port
contents" that spells out a port has installed, but it only works
after the fact. It has always seemed to be that it should tell you
what's in a port, regardless of whether it has been installed or not.
The avahi software's makefile itself installs the items into /System/
Library, bypassing the MacPorts destroot. It is by means of the
destroot that MacPorts knows what files a port contains, so a
hypothetical "dry run" command would not catch this either.
The hypothetical "dry run" command already exists anyway: "sudo port
destroot theport" and then look into the port's work/destroot
directory to see what's in there.
And to reprise an earlier thread, this is why I favor putting all
this stuff explicitly in /opt/local/{Library|/etc}/LaunchDaemons/
and putting the activation commands in the /etc/launchd.conf file.
True, that file exists outside the /opt sandbox but a couple of
lines that don't do anything in there make more sense than dangling
symlinks or worse, files written outside the sandbox that no one
knows about until something goes wrong.
Now, if launchd.conf supported an <include> syntax, we'd be home free.
I don't think that's relevant either. Again: it's not that the port
author was unaware that items should be installed in ${prefix}.
Rather, the ported software itself wrote these files to the wrong
place. Now that we have discovered that this is the case, the port
author has fixed the portfile and reported the problem upstream. I
don't think a general catch-all solution can be abstracted from this
experience.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
