https://bugs.kde.org/show_bug.cgi?id=369554
Bug ID: 369554
Summary: sleeper design bug in the installation layout due to
assumptions about filesystem case sensitivity
Product: buildsystem
Version: unspecified
Platform: Other
OS: other
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: general
Assignee: neund...@kde.org
Reporter: rjvber...@gmail.com
There is a design sleeper bug in the installation layout that has serious
effects when triggered. I see it throughout the frameworks and have to presume
it is made in other places too, which is why I am reporting it in this section
(the only relevant generic one that doesn't only have old-and-cold tickets).
The underlying issue here is that the design of at least the framework header
file tree assumes it is installed onto a case-sensitive filesystem. While this
is the norm on traditional Unix and Linux, conceivable for good reasons, it
simply isn't the norm in the rest of the world - and that rest is in fact a
(much) bigger target market.
The perfect illustration of this design bug ls in the KF5 frameworks header
file install locations. KF5 applies the usual convention that C headers are
lower-case and have a .h extension and C++ headers are capitalised and have no
extension: foo.h and Foo . A number of frameworks go beyond that, and put the C
headers in a subdirectory "foo" and the C++ headers in a directory "Foo". For
example:
KIOCore/KIO/Global
KIOCore/kio/global.h
Installing this on a case-insensitive filesystem 2 things may happen:
1) when KIO is created after kio (or vice-versa) an error is raised that the
directory already exists
2) the underlying routines consider KIO and kio to be the same directory, and
one ends up with
KIOCore/KIO/Global
KIOCore/KIO/global.h
or
KIOCore/kio/Global
KIOCore/kio/global.h
(presuming that the FS is case-preserving).
This is not a problem as long as the installed files are used only on the local
host (and the software itself doesn't reject an opened file if its path isn't
identical to the requested name).
The sleeper bug is triggered when installers are created on a case-insensitive
host and deployed on a case-sensitive host. That target host will receive the
same merged directory, but there the underlying system routines will take case
into account, and in this example, including "KIO/Global" or "kio/kio.h" will
fail.
We have had to deal with this bug on (Mac) OS (X) for a long time; in KDE4 days
it was limited to a select few of badly designed projects (like nepomuk-core).
At the moment I have only noticed this design issue in the header file install
location, which is of course an area that may not affect end-users so much. But
given that the issue is most likely the result of insufficient consideration of
all possible deployment targets it is bound to be present in other areas too.
Reproducible: Always
Steps to Reproduce:
1. Build any project on a host with case-insensitive filesystem
2. Create an installer
3. Deploy on a host with a case-sensitive filesystem
Actual Results:
If the project contains 'foo' and 'Foo' directories in the same parent
directory, these will be merged in the final install, either as 'foo' or as
'Foo' depending on the OS and the order of unpacking. As a result, opening
either "foo/foo.h" or "Foo/Foo" will fail.
This also happens on a case-insensitive filesystem, but there it is only a
problem if higher-level code checks the name of the file actually opened
against the expected name (i.e. if it rejects "Foo/foo.h" or "foo/Foo").
Expected Results:
No issues that result from assumptions about filesystem case sensitivity.
This design issue has implications for Mac and PC users. I have less view of PC
user practices, but it is quite common for more advanced Mac users to set their
system to case-sensitive, or at least use case-sensitive volumes (externals,
partitions, ...).
One easy way to get around this issue would be to test for and enforce
case-sensitivity in the build system, so that installers can only be created on
such systems. However, with the typical Mac way of installing by dragging an
application icon to the target destination that won't be enough. Users will
expect that they can drag their applications along with them, possibly
transporting them on a thumb drive or other media with a case-insensitive FS
like FAT32.
Note that Qt5 also uses "foo.h" C headers and "Foo" C++ headers (which then
include the C header). However, it installs both versions into the same
directory from the onset so the issue reported here shouldn't occur.
--
You are receiving this mail because:
You are watching all bug changes.
