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

[René J.V. Bertin]

On Sunday October 02 2016 13:02:07 Lawrence Velázquez wrote:

>something. Seems like it would be better to mount the image before
>launchd does anything, if possible.

That would require doing the mount the old-fashioned way. Not impossible, but I'd hate having to write an installer that modifies /etc/fstab

>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).

AFAIK `hdiutil attach` raises an error if there is a problem mounting the image, and if not the contents should be available, no?
I don't know how launchd handles failure in agents that aren't KeepAlive, I'd hope the job won't be considered loaded ...

>(You probably don't think there would be
>any issues. Users are very good at finding issues.)

Actually I'd be disappointed if they don't...

>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).

Why not, indeed. 

>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.

I think I've done similar things, though not as drastic. I vaguely recall putting a copy of MacPorts' bash into /bin, not realising it links to shared libraries in /opt/local that might not yet be available when the shell is started, or that might have been updated to a new incompatible version. I've had a dedicated admin account with an almost bone-stock set-up, but this required booting off a backup to get right.

I've tested the idea for the build directory today, using a sparse bundle. It works fine, and I got about 25% additional HFS compression on the unmounted image (mainly due to lingering destroot directories; most of the other content is already HFS compressed. But as expected the build times are longer (10-40%). The XBench results suggesting the contrary must have been due to consistent IO to the same bands, which remained cached as a result.
Still, this might have some value to port developers if they want to be able to generate exactly the same tarballs as the buildbots but don't want to bother with setting up a case-insensitive partition or boot disk.

R.