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

Lawrence Velázquez larryv at macports.org
Sat Oct 1 17:50:28 PDT 2016


> On Oct 1, 2016, at 7:19 PM, René J.V. Bertin <rjvbertin at gmail.com>
> wrote:
> 
>> On Saturday October 01 2016 23:13:25 Clemens Lang wrote:
>> 
>> People can already do that. People can also mount a different
>> filesystem at /opt/local. I just don't think that should be our
>> default setup.
> 
> I'm not saying it should be, this is just an idea for something that
> could be optional. It shouldn't be too difficult to provide as an
> option in an installer; the same cannot be said about other ways to
> mount a different filesystem at /opt/local.

Non-default configurations need to be compelling enough that base
developers are willing to develop, test, use, and support them on an
ongoing basis. I have a hard time believing that that condition would
hold here.

>> Sparse Bundles have the huge downside that they don't shrink
>> automatically. Yes, there are methods to shrink them, but that's
>> extra work and extra code.
> 
> I thought about that, but just how often does a typical MacPorts
> installation *shrink*? Look at it from the opposite side: with
> a sparse bundle you *can* shrink the size it takes up on shared disk
> space, something that's much less trivial if you use a dedicated
> partition for instance.


We don't really support dedicated partitions either, other than making
sure that symlinks resolve properly.

>> Additionally, I'd leave such a fundamental decision to Apple.
> 
> I don't see how this would be a fundamental decision that should be
> taken by Apple. They're supposed not to have any say over MacPorts at
> all.

They are the platform vendor. Every decision they make affects us.

The point is that case sensitivity is by and large a non-issue for us,
so our efforts are better spent accommodating the default filesystem —
whatever it is — rather than defying it in such a drastic manner.

>>> I also like the idea of being able to take the whole MacPorts tree
>>> offline with a simple command. 
>> 
>> A pretty uncommon use-case.
> 
> Because it typically isn't possible? O:-)

I fail to see why anyone would want to do this, even if they could.

But anyone who wants to can do so, right now, by following the
instructions you posted earlier, without any support from us.

vq


More information about the macports-dev mailing list