> On Oct 2, 2016, at 4:47 AM, René J.V. Bertin <rjvber...@gmail.com>
> wrote:
>
>> On Saturday October 01 2016 20:55:57 Lawrence Velázquez wrote:
>>
>> So what happens when a port-installed Launch{Agent,Daemon} is loaded
>> before the one that mounts the entire MacPorts prefix?
>
> A priori they won't if their plists are symlinks into ${prefix}.
> Something similar happens when your prefix sits on another volume. Or
> used to happen to me at some point; launchd simply deferred loading
> the plists in question as far as I've ever able to tell.
I forgot that we generally link the launchd stuff. I guess that's…
something. Seems like it would be better to mount the image before
launchd does anything, if possible.
> Actually, making a prefix load through a lauchd agent means all
> launchd agents and daemons under that prefix can the OtherJobEnabled
> key to signal that they depend on the prefix job.
OtherJobEnabled is fragile because it only ensures that the other job is
loaded, not whether the condition we care about is met (in this case,
whether the contents of the image are mounted and available).
>> We don't really support dedicated partitions either, other than
>> making sure that symlinks resolve properly.
>
> What's there to support about a dedicated partition that's mounted on
> /opt/local?
Nothing, if the user sets it up themselves. That's fine, and anyone who
wants to experiment is welcome to do so. This is already our position on
replacing various bits of the prefix tree with symlinks elsewhere.
On the other hand, offering it as an install-time option would at
a minimum involve adding code to the build system and helping users with
any issues that might arise. (You probably don't think there would be
any issues. Users are very good at finding issues.)
> Either way, much as I like this idea I didn't expect for minute that
> it would receive a very warm welcome. OK, I kind of expected I'd get
> at least 1 "yeah, that'd be cool" kind of reaction, but I probably
> should have known better.
Don't get me wrong; it's a neat idea. Might even be worth writing up
a wiki page for anyone else who's interested in such a setup (with
healthy doses of caveat emptor).
> Thing is that some of the aspects I find appealing won't apply to me
> anyway; unmounting the image will be complicated for instance as
> I have my login shell set to one installed through MacPorts (tcsh).
I once made the mistake of removing MacPorts from a long-dormant 10.5 or
10.6 VM, intending to start over from scratch, forgetting that my login
shell was /opt/local/bin/zsh. Didn't realize it until Terminal.app and
ssh started failing. Ended up creating a new admin user to fix it with
chsh and making my zsh startup files compatible with 4.x so I didn't
have to install a new zsh on old systems. Good times.
vq
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
