[Development] Co-installation & library naming rules

[Shawn Rutledge]

On 27 September 2012 06:01, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer at gmail.com> wrote:
> IIRC, in Debian with Qt3 and Qt4 we did have both libs installed without
> problems. With respect the other stuff:
>
> - qmake, moc et al.: we used divertions (an apt facility) to let the user
> choose which one to use on compiling stuff. Binaries were renamed upon
> packaging to qmake-qt3/qmake-qt4 and a simlink points to one of them (thanks
> to the aforementioned divertions system).
>
> - Headers: I *think* thet could be installed at the same time. What was done
> to make it happen is a detail I don't know/remember, as I wasn part of the
> packaging team and we already removed qt3 from the archive.

Those are good points.  Co-installation requires worrying about more
than just libraries.  For example on Arch Linux I have both python 2.7
and 3.2 installed, because they are incompatible, and some packages
require one or the other.  So there are lots of links:

lrwxrwxrwx 1 root root     7 Aug 20 14:48 /usr/bin/python -> python2
lrwxrwxrwx 1 root root     9 Apr 24 02:02 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root  6248 Apr 24 02:02 /usr/bin/python2.7
-rwxr-xr-x 1 root root  1618 Apr 24 02:02 /usr/bin/python2.7-config
lrwxrwxrwx 1 root root    16 Apr 24 02:02 /usr/bin/python2-config ->
python2.7-config
lrwxrwxrwx 1 root root    55 Jul 26 19:34 /usr/bin/python2-pykdeuic4
-> /usr/lib/python2.7/site-packages/PyQt4/uic/pykdeuic4.py
-rwxr-xr-x 1 root root    94 Jul 17 19:55 /usr/bin/python2-pyuic4
-rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3
-rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3.2
lrwxrwxrwx 1 root root    18 Apr 24 01:27 /usr/bin/python3.2-config ->
python3.2mu-config
-rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3.2mu
-rwxr-xr-x 1 root root  1821 Apr 24 01:27 /usr/bin/python3.2mu-config
lrwxrwxrwx 1 root root    16 Apr 24 01:27 /usr/bin/python3-config ->
python3.2-config
-rwxr-xr-x 1 root root  1193 Aug 13 23:19 /usr/bin/python3-mako-render
lrwxrwxrwx 1 root root    14 Apr 24 01:27 /usr/bin/python-config ->
python3-config

whereas for the libs, there is just /usr/lib/python2.7/ and
/usr/lib/python3.2/, and includes are in /usr/include/python2.7/ and
/usr/include/python3.2mu/ .

Maybe we need to also rename the qt binaries for which the version
matters?  especially qmake.  Why should the distros have to rename it
themselves?  If qmake5 becomes the standard name, they won't have to
rename this or future versions.  The alternative would be to install
all the binaries in their own directory somewhere and make links to
them from /usr/bin, but packagers probably already know about the
-bindir option to configure; and each distro has its own way of
making/updating the "alternatives" links.

Likewise there could be named include dirs like
/usr/include/qt5/QtCore or something like that.  (It cannot be
/usr/include/Qt5Core because of the habit of doing #include
<QtCore/ClassName> .) Config has -headerdir but maybe the default
should be version-specific.

I'm way in favor of finally getting rid of the default prefix like
/usr/local/Trolltech or /usr/local/Qt-something.  I always thought
that was ridiculous, not at all what anyone wants, and didn't realize
for a long time what could be the reason for it, other than hubris, or
a desire to replicate the Windows situation on Linux
(c:\progra~1\MyIllustriousCompany\WhizBangProduct\binary.exe).  It's
unfortunate that people developing embedded systems often don't follow
the FHS, and having defaults like that just helps to reinforce their
bad habits.  It could at least have defaulted to /opt/QtX for many
years already.

Defaulting to a more standard-looking installation in /usr/local/bin,
/usr/local/lib, /usr/local/include, /usr/local/share/qt5/examples,
etc. while still permitting co-installation will really be the best I
think.  Packagers maybe would only have to override -prefix to /usr.
But how to handle co-installation of the binaries is still a good
question.  Probably the ones that need to go in /usr/bin need to have
version suffixes?