avahi port installs org.freedesktop.* files

[Ryan Schmidt]

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.