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.
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.
> 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? The only thing I see that wouldn't work across partitions is
hard-linking, but why would a port hard-link to a file outside the prefix?
> They are the platform vendor. Every decision they make affects us.
That, yes, and too much so in a sense. But as far as case-sensitivity and this
idea of mine goes, Apple provide everything required :)
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.
I'm still debating whether or not I'm going to try this myself as it's high
time I do something about the free-space fragmentation on the volume holding my
prefix anyway. 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). That makes it just
as difficult to run disk repair, DiskWarrior or iDefrag on the volume, except
that I know those are operations that monopolise the whole machine. Doing
maintenance on a disk image is something I'd expect to be able to do in the
background, I fear.
I'm more likely to experiment with the build directory on a sparse bundle (if
not only to see if those XBench results translate into real world reduction of
build times).
R.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
