On Oct 1, 2007, at 17:52, paul beard wrote:
On 10/1/07, Ryan Schmidt wrote:
In the current way, the symlink is made in the destroot and handled
just like any other file in the port's manifest. On activate, it is
installed to the right place. On deactivate, it is removed. To start
the service, you "launchctl load" it and to stop it, you "launchctl
unload" it. This is all fairly easy and works.
This assumes that people deactivate or otherwise that allow
MacPorts to clean up after itself. rm -rf /opt/local would leave
those broken symlinks. They don't really matter but as I said
earlier, the "nothing outside /opt/local" rule is bent in some
cases, this being one.
Yes, we do want MacPorts to install as much as possible inside $
{prefix}. But currently some things do get installed outside of the
prefix. But IMHO the current uninstall instructions adequately
address this issue. BTW, "rm -rf /opt/local" is not the extent of the
uninstall instructions:
http://trac.macosforge.org/projects/macports/wiki/
FAQ#HowdoIremoveoruninstallMacPorts
And as for invoking launchct load statements, how is this different?
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/
org.macports.dbus.plist
launchctl load /opt/local/etc/LaunchDaemons/org.macports.apache2/
org.macports.apache2.plist
launchctl load /opt/local/etc/LaunchDaemons/org.macports.mysql5/
org.macports.mysql5.plist
from putting the plists in launchd's default search path? As
configured, launchctl looks in two places for plists: in /System/
Library/LaunchDaemons, for Apple-owned stuff, in /Library/
LaunchDaemons for user-installed/third-party stuff. I don't see a
big deal about another repository for plists. Maybe in future
releases launchd will allow additional directories to be added
instead of individual lines.
Your way would require someone to manually edit the file /etc/
launchd.conf, at least to remove a line from it. That's more
complicated than the current way, where a single launchctl line
starts or stops the service. Also, with your way, the service
wouldn't start or stop until the next startup. That's worse than what
we have now, where the service starts or stops immediately.
see above: if launchctl works as it says on the tin, there is not
different between symlinks that point to /Library/LaunchDaemons and
the lines I have in /etc/launchd.conf.
Wait. Currently, MacPorts automatically puts the symlinks in /Library/
LaunchDaemons, then instructs you how to load (start) and unload
(stop) as needed. Your proposition as I understood it was that the
user would manually add and remove lines in /etc/launchd.conf. Are
you now suggesting instead that MacPorts would automatically put the
lines in /etc/launchd.conf? If so, why is that preferable to the
current way? Currently, we add symlinks in /Library/LaunchDaemons,
which is outside of ${prefix}. You propose modifying /etc/
launchd.conf, which is also outside of ${prefix}. At least the
symlinks in /Library/LaunchDaemons have "macports" in the filenames
so they're easier to find, and getting rid of them is as simple as a
single "rm" command. Getting rid of a line in a conf file is more
involved.
Also, since I'm not familiar with /etc/launchd.conf, I assume that
the file is only scanned at system startup. Is that the case? If so,
then adding to that file is worse than what we have now, where
"launchctl load" will load the service immediately, and cause it to
start at every subsequent system startup. Unless you're suggesting
that the user should modify /etc/launchd.conf, and then also use the
launchctl command to start the service now. If so, you've just added
an extra step for the user, again for no apparent benefit.
Running a single launchctl command to start or stop a service is
easy. Conversely, adding a line to a file is easy, as you showed, but
removing a line from a file requires a more elaborate script. So why
change it to make it more difficult?
I'm not arguing in favor of it. I'm just explaining it. I have a
hard time believing that, given the power on tap, that there is no
way to add a commented line to /etc/launchd.conf
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/
org.macports.dbus.plist # installed by macports
and add a # character to the beginning of the line containing the
comment:
sed -e s/^launchctl/#&/g <- yes, I know that won't work, but you
get the idea: sed is not my native language.
Yes, of course it's possible to write something with sed or similar
that adds or removes a specific line from a file. My point is that
it's more difficult than executing a single launchctl statement. And
since the current way works, I didn't understand why you think it's
better to complicate things.
There's a slight problem with the current way. If the service is
running at the time that you uninstall the port, the software stays
running. And if the service is running at the time that you upgrade
the port, the old version stays running and the new version's plist
says the software isn't running and it's inconvenient to fix that
(manually edit the plist to show that the software is running,
launchctl unload the software, launchctl load it again). Would your
new way solve either of these problems? (I haven't tried so I don't
know.)
Is there no pre-install step that could stop the service with the
existing plist, install, restart?
I don't think MacPorts should be stopping or starting any services
automatically. That could be unexpected and bad.
I've been meaning to submit bug reports about these situations but
hadn't gotten around to it yet.
Again, I'm not arguing in favor of doing it this way, I'm just
explaining it. Perhaps if it's more clearly understood, a
comparison can be made.
Ok. Then I'll say that I acknowledge that MacPorts could do it your
way instead of how it does it now, but I don't see any advantage to
making that change at this point, rather I currently see
disadvantages, so I don't think MacPorts should change this right
now, until someone shows why it's better.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
