${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

[René J.V. Bertin]

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.