Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread René J . V . Bertin 
On Friday September 30 2016 03:48:09 Ryan Schmidt wrote:

> > Still: https://bugs.kde.org/show_bug.cgi?id=369554
> 
> Thanks.

Also see https://git.reviewboard.kde.org/r/127822/ for a prototype fix I 
started working on months ago...

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Sierk Bornemann 

> Am 30.09.2016 um 17:30 schrieb Lawrence Velázquez :
> 
>> On Sep 30, 2016, at 11:17 AM, Sierk Bornemann  wrote:
>> 
>> If you were right - why then implementing then case-sensitivity in the
>> first place instead of firstly implementing case-insensitivity?
> 
> I am no expert, but isn't implementing a case-sensitive filesystem
> *easier*? The classic Unix "bag of bits" is already inherently
> case-sensitive.

Seethe road, Apple already has taken since years with iOS, which is 
case-sensitive.

> My point is that we should not make assumptions about Apple's plans for the 
> future.

And my point is: go further than assumptions. Know and make sure, clarify it, 
read Apple developer documentations, if that does not suffice, ask an Apple 
expert/intern who really knows, if you yourself don’t know. :)


Regards,
Sierk
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Lawrence Velázquez 
> On Sep 30, 2016, at 11:17 AM, Sierk Bornemann  wrote:
> 
> If you were right - why then implementing then case-sensitivity in the
> first place instead of firstly implementing case-insensitivity?

I am no expert, but isn't implementing a case-sensitive filesystem
*easier*? The classic Unix "bag of bits" is already inherently
case-sensitive.

> I, on your stead, would assume that Apple finally here begins to
> practically fulfill a years-long indicated paradigm change - towards
> case-sensitivity per default.

I am not interested in arguing about the merits of case (in)sensitivity
or guessing whether APFS will be case sensitive by default. My point is
that we should not make assumptions about Apple's plans for the future.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Lawrence Velázquez 
> On Sep 30, 2016, at 11:10 AM, René J.V. Bertin  wrote:
> 
>> On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote:
>> 
>> So users would have to have this disk image mounted at all times, just
>> in case they ever want to use anything installed by MacPorts?
> 
> Yes, but that can be completely transparent. The image can be mounted at an 
> appropriate time during the boot sequence, possibly on-demand by launchd. And 
> it can be configured not to show up as a volume on the desktop.
> Use a dynamically sized (sparse) disk image, and you get very close to ZFS 
> dataset.

That sounds like more work than it's worth.

>> Your moralizing is not appreciated. Cut it out.
>> Rest assured, "MacPorts" does not agree with your PoV on anything.
> 
> Your aggressiveness and overgeneralisation aren't appreciated either, cut 
> that out too.

You first.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Sierk Bornemann 

> Am 30.09.2016 um 16:28 schrieb Lawrence Velázquez :
> 
>> On Sep 30, 2016, at 10:15 AM, Sierk Bornemann  wrote:
>> 
>>> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>>> 
 Apple could (and IMHO should) have made case-sensitivity the
 default and let everyone come to term with the fact that foo and
 Foo are not the same thing (or add normalising glue code in their
 highlevel APIs).
>>> 
>>> 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.
>> 
>> Past/presence. But: Apple seems finally to go into case-sensitive per
>> default resp. case-sensitive-only:
>> 
>> Apples forthcoming APFS is/will be case sensitive per default, and
>> relating Sierra so far is case sensitive-only (when, if at all
>> case-insensitivity will be implemented, only Apple knows):
> 
> Given the nature of the other items on that list (no startup volumes, no
> Time Machine, no FileVault), it would be highly imprudent to assume that
> case-sensitivity-by-default is anything other than a corner that was cut
> to get the Developer Preview out the door.
> 
> vq

If you were right - why then implementing then case-sensitivity in the first 
place instead of firstly implementing case-insensitivity?
I, on your stead, would assume that Apple finally here begins to practically 
fulfill a years-long indicated paradigm change - towards case-sensitivity per 
default. Finally.
I think further, it would worth a check, if POSIX 2008 conformance on which the 
fresh Single UNIX Specification version 4 (SUSv4) of this current year 2016 
also mandats case-sensitivity per default, as I can read the POSIX 2008 
specification site on Open Group: 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html

[quote]
The Open Group Base Specifications Issue 7, IEEE Std 1003.1-2008, 2016 Edition, 
Copyright © 2001-2016 The IEEE and The Open Group
2. Conformance
2.1 Implementation Conformance
For the purposes of POSIX.1-2008, the implementation conformance requirements 
given in this section apply.
2.1.1 Requirements
A conforming implementation shall meet all of the following criteria:
[…]
The system may provide non-standard extensions. These are features not required 
by POSIX.1-2008 and may include, but are not limited to:
[…]
• Non-conforming file systems (for example, legacy file systems for 
which _POSIX_NO_TRUNC is false, case-insensitive file systems, or network file 
systems)
[…]
[/quote]

Apples OS X incl. Sierra so far conforms to SUSv3 based on (the old) POSIX 2001 
(meanwhile POSIX 2004 and POSIX 2008 have been published years ago).


Maybe a further inspection worth, which path Apple will go per default, if APFS 
is stable and shipped? Maybe asking some expert from Apple directly, who have 
insight and know more?
Case-insensitivity per default on Apples systems seems to come to en end. More 
than ever, if you realize, that in iOS, being the case sensitive HFSX by 
default.

And so https://developer.apple.com/library/content/qa/qa1697/_index.html

states:

[quote=Apple]Case-sensitivity: iPhone OS uses a case-sensitive file system, 
unlike the Simulator which uses a case-insensitive file system by default. Make 
sure the case-sensitivity of resources accessed within code matches the 
filename case-sensitivity.
[/quote]

Apple walks the case-sensitive path, with iOS being case sensitive per default 
since years, and they advice the developers since a very while to walk that 
path too and to make and assure their applications and their filesystem 
handling to be case sensitive. And OS X/macOS now marches the same path - 
towards case sensitivity per default, it will follow, all signs undeniably 
point to that direction. Finally!


Regards,
Sierk
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread René J . V . Bertin 
On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote:

> So users would have to have this disk image mounted at all times, just
> in case they ever want to use anything installed by MacPorts?

Yes, but that can be completely transparent. The image can be mounted at an 
appropriate time during the boot sequence, possibly on-demand by launchd. And 
it can be configured not to show up as a volume on the desktop.
Use a dynamically sized (sparse) disk image, and you get very close to ZFS 
dataset.

> Your moralizing is not appreciated. Cut it out.
> Rest assured, "MacPorts" does not agree with your PoV on anything.

Your aggressiveness and overgeneralisation aren't appreciated either, cut that 
out too.

> On Friday September 30 2016 16:09:43 Sierk Bornemann wrote:
> > case sensitive per default, and relating Sierra so far is case
> > sensitive-only

I don't understand that; 10.12 installs to a case-sensitive HFS filesystem? 
Does it actually convert existing disks?

> > (when, if at all case-insensitity will be implemented,
> > only Apple knows).

I consider this good news, possibly the best thing (= with the most day-to-day 
usefulness) yet I've read about APFS (ApFS?! :)), together with "space sharing" 
if that's indeed comparable to ZFS datasets.
Case-insensitivity for Apple's target users doesn't have to be implemented at 
the FS level, I think. The user interface can provide natural language search 
facilities and handle mismatches in case transparently in the rare cases where 
you actually get to type in a filename to be opened without backup from a GUI 
that shows the matching filenames.

In fact, it should be possible to provide low/FS-level support to mimick the 
behaviour of case-insensitive HFS on top of actual case-sensitivity. If a file 
or path doesn't exist in the exact spelling, check if it exist disregarding 
case and if so use that instance. You'd probably not want to do that for 
creation, though :)

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Lawrence Velázquez 
> On Sep 30, 2016, at 10:15 AM, Sierk Bornemann  wrote:
> 
>> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>> 
>>> Apple could (and IMHO should) have made case-sensitivity the
>>> default and let everyone come to term with the fact that foo and
>>> Foo are not the same thing (or add normalising glue code in their
>>> highlevel APIs).
>> 
>> 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.
> 
> Past/presence. But: Apple seems finally to go into case-sensitive per
> default resp. case-sensitive-only:
> 
> Apples forthcoming APFS is/will be case sensitive per default, and
> relating Sierra so far is case sensitive-only (when, if at all
> case-insensitivity will be implemented, only Apple knows):

Given the nature of the other items on that list (no startup volumes, no
Time Machine, no FileVault), it would be highly imprudent to assume that
case-sensitivity-by-default is anything other than a corner that was cut
to get the Developer Preview out the door.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Lawrence Velázquez 
> On Sep 30, 2016, at 4:44 AM, René J.V. Bertin 
> wrote:
> 
>> 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).

Case-insensitive and case-preserving are not the same thing.

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

Your moralizing is not appreciated. Cut it out.

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

We are not talking about about computer science. We are talking about
the Mac platform, on which most filesystems are case-insensitive.

> And in general MacPorts seem to agree with my PoV

Rest assured, "MacPorts" does not agree with your PoV on anything.

> otherwise the build bots wouldn't have used a case-sensitive
> filesystem.

We are in full control of those systems, so it's feasible for us to use
HFSX there. We do not control our users' systems.

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

Our "simple reality" is that most of our users do not use HFSX, and
there's an equally strong argument to be made that we should not be
crusading against *that*.

vq

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Sierk Bornemann 
> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>> Apple could (and IMHO should) have made case-sensitivity the default and let 
>> everyone come to term with the fact that foo and Foo are not the same thing 
>> (or add normalising glue code in their highlevel APIs).

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

Past/presence. But: Apple seems finally to go into case-sensitive per default 
resp. case-sensitive-only:
Apples forthcoming APFS is/will be case sensitive per default, and relating 
Sierra so far is case sensitive-only (when, if at all case-insensitivity will 
be implemented, only Apple knows):

Apple Developer Library: Apple File System Guide: FAQ: Compatibility
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html#//apple_ref/doc/uid/TP40016999-CH6-DontLinkElementID_1

[quote]
Q: What are the limitations of Apple File System in macOS Sierra?
A: […]
° Case Sensitivity: Filenames are case-sensitive only.
[…]
[/quote]

ars technica (6/13/2016): Digging into the dev documentation for APFS, Apple’s 
new file system
http://arstechnica.com/apple/2016/06/digging-into-the-dev-documentation-for-apfs-apples-new-file-system/

[quote]
Perhaps most importantly, the file system currently is case-sensitive, and this 
cannot be disabled. HFS+ breaks with most Unix-y file systems in that it can be 
configured to not use case sensitivity; in fact, running OS X—ahem, macOS, 
sorry—with case-sensitive HFS+ can lead to its own problems. But, for now, if 
you want to use APFS, you’re going to do so on a non-startup volume, and you’re 
going to have to deal with case sensitivity.
[/quote]





Sierk Bornemann
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Lawrence Velázquez 
> On Sep 30, 2016, at 3:39 AM, René J.V. Bertin 
> wrote:
> 
>> On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:
>> 
>>> But why do it only for ${workpath}; the whole of ${prefix} could be
>>> on a case-sensitive RW dynamically-sized disk image (a sparse
>>> bundle?) that gets created by the MacPorts installer, with some
>>> magic to get it to mount automagically at the right time.
>>> 
>>> That would solve all case-sensitivity issues once and for all (or
>>> almost), without need for telling users to convert their whole
>>> (boot) volume to case-sensitivity. It's probably less easy to
>>> implement than it sounds, but maybe it's something to consider?
>> 
>> This sound convoluted. Also remember that MacPorts is not confined to
>> installing files in ${prefix}. 
> 
> A tad, maybe. Anything that gets installed outside of ${prefix} is
> largely out of control, but it's probably also safe to say that those
> files are where they are because they're somehow specific to the OS
> and thus don't make assumptions about filename case. 

So users would have to have this disk image mounted at all times, just
in case they ever want to use anything installed by MacPorts?

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread René J . V . Bertin 
On Friday September 30 2016 03:48:09 Ryan Schmidt wrote:

>> Still: https://bugs.kde.org/show_bug.cgi?id=369554
>
>Thanks.

Let's not hold our breath though. Addressing this issue properly will be very 
invasive: lots of dependent code will require patches. And even if the patching 
can be done more or less automatically the patched code will then be locked to 
the latest version of the frameworks.

The only lever I really see is the fact that there has been a growing idea that 
KDE apps should behave as natively as possible; so support bundling as 
standalone app bundles on OS X. That will include support for dragging to and 
from FAT32 thumbdrives without breakage, and that's probably possible only if 
you make no assumptions at all about filename case.

Note however that MacPorts' reproducible-build principle also kind of imposes 
the use of a case-sensitive FS at the user end. I think that's the only way to 
guarantee that users build exactly the same binary images as the build bots 
do... ;)

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Ryan Schmidt 

> On Sep 30, 2016, at 3:44 AM, René J.V. Bertin  wrote:
> 
> Still: https://bugs.kde.org/show_bug.cgi?id=369554

Thanks.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread René J . V . Bertin 
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.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread Ryan Schmidt 

On Sep 30, 2016, at 2:39 AM, René J.V. Bertin wrote:

> On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:
> 
>>> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
>>> standardised the behaviour of using capitalised letters in C++ header 
>>> filenames. 
>> 
>> Someone needs to make it clear to them that this is not a good idea. Not all 
>> filesystems are case sensitive. Mac OS has been around since 1984, always by 
>> default with a case insensitive filesystem, and Mac OS is used by a lot more 
>> people than Linux, so nobody has any excuse to be surprised by this anymore 
>> or to ignore this problem.
> 
> I agree but you do realise that Apple themselves do the same thing in their 
> SDK headers?

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.

> AppKit.h etc. C++ headers don't have an extension, or else a different one 
> (.hpp; see boost). IOW, aliasing isn't possible. The practice of putting 
> different classes of headers in directories with names distinguished only by 
> case is a much bigger problem, as we've seen.
> Don't forget that MS Windows also uses case-insensitive file systems by 
> default, and at least for Qt that most likely represents a much bigger 
> market. But that's ... Messy Windows Apple could (and IMHO should) have 
> made case-sensitivity the default and let everyone come to term with the fact 
> that foo and Foo are not the same thing (or add normalising glue code in 
> their highlevel APIs).

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.


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


>>> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
>>> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
>>> created by the MacPorts installer, with some magic to get it to mount 
>>> automagically at the right time.
>>> 
>>> That would solve all case-sensitivity issues once and for all (or almost), 
>>> without need for telling users to convert their whole (boot) volume to 
>>> case-sensitivity. It's probably less easy to implement than it sounds, but 
>>> maybe it's something to consider?
>> 
>> This sound convoluted. Also remember that MacPorts is not confined to 
>> installing files in ${prefix}. 
> 
> A tad, maybe. Anything that gets installed outside of ${prefix} is largely 
> out of control, but it's probably also safe to say that those files are where 
> they are because they're somehow specific to the OS and thus don't make 
> assumptions about filename case. 
> 
>> Projects should not assume case sensitive filesystems.
> 
> That's a bit arrogant as a statement...

Maybe, but I'm sticking by it.

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


>> I don't recall that, but maybe I forgot.
> 
> One thing is certain: GNU cp will raise an overwrite error when copying a 
> tree containing directories (and files?) differing only in case to a 
> case-insensitive location. Mac cp and BSD tar don't (the latter not even on 
> Linux).

Ok.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-30 Thread René J . V . Bertin 
On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:

>> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
>> standardised the behaviour of using capitalised letters in C++ header 
>> filenames. 
>
>Someone needs to make it clear to them that this is not a good idea. Not all 
>filesystems are case sensitive. Mac OS has been around since 1984, always by 
>default with a case insensitive filesystem, and Mac OS is used by a lot more 
>people than Linux, so nobody has any excuse to be surprised by this anymore or 
>to ignore this problem.

I agree but you do realise that Apple themselves do the same thing in their SDK 
headers? AppKit.h etc. C++ headers don't have an extension, or else a different 
one (.hpp; see boost). IOW, aliasing isn't possible. The practice of putting 
different classes of headers in directories with names distinguished only by 
case is a much bigger problem, as we've seen.
Don't forget that MS Windows also uses case-insensitive file systems by 
default, and at least for Qt that most likely represents a much bigger market. 
But that's ... Messy Windows Apple could (and IMHO should) have made 
case-sensitivity the default and let everyone come to term with the fact that 
foo and Foo are not the same thing (or add normalising glue code in their 
highlevel APIs).

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.

>> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
>> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
>> created by the MacPorts installer, with some magic to get it to mount 
>> automagically at the right time.
>> 
>> That would solve all case-sensitivity issues once and for all (or almost), 
>> without need for telling users to convert their whole (boot) volume to 
>> case-sensitivity. It's probably less easy to implement than it sounds, but 
>> maybe it's something to consider?
>
>This sound convoluted. Also remember that MacPorts is not confined to 
>installing files in ${prefix}. 

A tad, maybe. Anything that gets installed outside of ${prefix} is largely out 
of control, but it's probably also safe to say that those files are where they 
are because they're somehow specific to the OS and thus don't make assumptions 
about filename case. 

>Projects should not assume case sensitive filesystems.

That's a bit arrogant as a statement... There are simply a lot of them that do, 
and most of them *will* consider the Mac a niche "market". 

>I don't recall that, but maybe I forgot.

One thing is certain: GNU cp will raise an overwrite error when copying a tree 
containing directories (and files?) differing only in case to a 
case-insensitive location. Mac cp and BSD tar don't (the latter not even on 
Linux).

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-29 Thread Ryan Schmidt 

> On Sep 29, 2016, at 5:10 AM, René J.V. Bertin  wrote:
> 
> On Thursday September 29 2016 07:14:11 MacPorts wrote:
>> #49559: nepomuk-core can't be installed on a case-sensitive system
> 
> Hi,
> 
>> The new buildbot setup does not show this behavior, so I revbumped
>> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
>> case-sensitive systems. See also #42904.
> 
> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
> standardised the behaviour of using capitalised letters in C++ header 
> filenames. 

Someone needs to make it clear to them that this is not a good idea. Not all 
filesystems are case sensitive. Mac OS has been around since 1984, always by 
default with a case insensitive filesystem, and Mac OS is used by a lot more 
people than Linux, so nobody has any excuse to be surprised by this anymore or 
to ignore this problem.


> I've been thinking recently about how this kind of thing could be avoided, in 
> relation to my earlier question about the build directory. I toyed with the 
> idea that instead of being a simple subdirectory, ${workpath} could be the 
> mountpoint of a RW dmg with appropriate filesystem settings, like 
> case-sensitivity. 
> 
> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
> created by the MacPorts installer, with some magic to get it to mount 
> automagically at the right time.
> 
> That would solve all case-sensitivity issues once and for all (or almost), 
> without need for telling users to convert their whole (boot) volume to 
> case-sensitivity. It's probably less easy to implement than it sounds, but 
> maybe it's something to consider?

This sound convoluted. Also remember that MacPorts is not confined to 
installing files in ${prefix}. Projects should not assume case sensitive 
filesystems.


> Something else: I seem to recall preprocessor errors either on `#include 
> ` or `#include ` even if the underlying system calls 
> (fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless 
> the exact case, on a case-insensitive HFS. I can no longer reproduce this, 
> but has that been a known issue at some point? Or is it just a figment of my 
> imagination (if not simply the result of a testing error)?

I don't recall that, but maybe I forgot.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

2016-09-29 Thread René J . V . Bertin 
On Thursday September 29 2016 07:14:11 MacPorts wrote:
>#49559: nepomuk-core can't be installed on a case-sensitive system

Hi,

> The new buildbot setup does not show this behavior, so I revbumped
> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
> case-sensitive systems. See also #42904.

Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
standardised the behaviour of using capitalised letters in C++ header 
filenames. 

I've been thinking recently about how this kind of thing could be avoided, in 
relation to my earlier question about the build directory. I toyed with the 
idea that instead of being a simple subdirectory, ${workpath} could be the 
mountpoint of a RW dmg with appropriate filesystem settings, like 
case-sensitivity. 

But why do it only for ${workpath}; the whole of ${prefix} could be on a 
case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
created by the MacPorts installer, with some magic to get it to mount 
automagically at the right time.

That would solve all case-sensitivity issues once and for all (or almost), 
without need for telling users to convert their whole (boot) volume to 
case-sensitivity. It's probably less easy to implement than it sounds, but 
maybe it's something to consider?

Something else: I seem to recall preprocessor errors either on `#include 
` or `#include ` even if the underlying system calls 
(fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless the 
exact case, on a case-insensitive HFS. I can no longer reproduce this, but has 
that been a known issue at some point? Or is it just a figment of my 
imagination (if not simply the result of a testing error)?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev