[Development] Summary of renaming changes
Joerg.Bornemann at digia.com
Sun Oct 21 17:48:05 CEST 2012
> > This *is* the problem of Linux distributions. FHS doesn't cover this
> > problem properly and this is the point where it should be fixed.
> > You're making life harder for every platform - not only Linux - by
> > fixing their problem.
> You may argue that case, but they'll argue back that this solution has worked
> quite well for almost all packages for over a decade.
OK I'm accepting reality and that what worked for so long is assumed to
be the right way and won't be changed. I'm even going so far to admit that
we might have to act. :)
What still is questionable is the way of doing that. What we have is a naming
clash between two installed versions. IMHO the least elegant way is to rename
all relevant files in one of these versions. For these kind of conflicts there
are namespaces. Every file system that's relevant to our case has a namespace
Apparently this feature is out for /usr/bin. Even /usr/bin/X11 is a symlink to
/usr/bin on Debian wheezy that I'm using here. But hey, here's an interesting
example: llvm. Binaries are in /usr/lib/llvm-3.0/bin and /usr/bin contains
symlinks to its contents. These symlinks end with llvm's version number.
Same pattern applies to the 2.7 llvm version that's installed here.
Why can't we have something alike for Qt?
If your fear is that different distros use different link names then please take
these things into consideration:
- Our target audience is software developers, they'll be able to enter qmake,
press TAB twice and choose the right link. (Well if the version number is
appended and not prepended, anyways.)
- We can publish a recommendation for packaging Qt.
- Some distros might want to use a different naming scheme.
If all of this is totally impossible then please add a configure option that's
off by default, like -qtlibinfix.
More information about the Development