[MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)
René J.V. Bertin
rjvbertin at gmail.com
Fri Sep 30 01:44:11 PDT 2016
On Friday September 30 2016 02:53:22 Ryan Schmidt wrote:
>I am not aware of Apple installing files whose names differ only by case; it wouldn't make sense for them to do so, given that the default filesystem is case-insensitive and can't accommodate that. If you believe they do install files that way, please give a specific example.
No, I didn't say that, and you're right that makes it less of an issue (but still a bad idea to rely on a case-preserving feature, IMHO).
>Apple has decided Mac OS has a case-insensitive filesystem by default; it's pointless to talk about what you think they should have done; they didn't do that.
I don't agree; it's never too late to repent and do the right thing (in general).
>> Also: until the late nineties or whenever Mac OS X was first released, Mac OS wasn't a Unix OS. Until that time, Macs under Unix either ran some version of A/UX or Linux, both of which only had case-sensitive native filesystems.
>
>*That* was niche.
Yep. A niche application of a computer family that was more and more of a niche itself...
>> That's a bit arrogant as a statement...
>
>Maybe, but I'm sticking by it.
That's your right, but don't think you have the "moral high ground". Or do you consider that nothing in computer science and application should be case-sensitive?
>
>> There are simply a lot of them that do, and most of them *will* consider the Mac a niche "market".
>
>They should be educated about their error.
Again, arrogance. This is an error only in the commercial sense. There is no error in considering the Mac a niche "market" of Gnome applications, for instance. And in general MacPorts seem to agree with my PoV; otherwise the build bots wouldn't have used a case-sensitive filesystem.
It's simple reality: a probably big majority of the ports provided come from a universe where case-sensitivity is the norm, and there's no point in crusading against this or projects making assumptions about it. Be it implicitly, or explicitly (by comparing the obtained path to the requested path, as I thought the compiler did). When individual ports break because of this you can try to do something about it upstream, but as a general attitude it would be Don Quixote'sque.
Still: https://bugs.kde.org/show_bug.cgi?id=369554
R.
More information about the macports-dev
mailing list