Hi Artur,
thanks for working on this bug. Let me first a clarify a
misunderstanding in your comment #15:
I wrote:
> 2. Provide directories /usr/share/libqglviewer-qt{3,4}, similar to
> /usr/share/qt{3,4}, with symlinks to the real locations. These
> directories
> should contain all the necessary stuff such one can pass this
> directory to
> the configuration script of any build system without requiring further
> modifications.
You replied:
> I am afraid that's not the case. Some files from Qt3 and Qt4 are
> installed
> in standard locations but with -qt3 or -qt4 suffix. So, there are, for
> example:
> /usr/bin/moc-qt3
> /usr/bin/moc-qt4
> /usr/bin/qmake-qt3
> /usr/bin/qmake-qt4
> and following symlinks:
> /usr/share/qt3/bin/moc -> ../../../bin/moc-qt3
> /usr/share/qt4/bin/moc -> ../../../bin/moc-qt4
> /usr/share/qt3/bin/qmake -> ../../../bin/qmake-qt3
> /usr/share/qt4/bin/qmake -> ../../../bin/qmake-qt4
> Most files in qglviewer are installed in different location for each
> flavour. With exception of shared library files - they comes to
> /usr/lib.
My argument was that the directories similar to /usr/share/qt{3,4} could
be *added* for libqglviewer such that such a directory could be passed
as --prefix argument to other configure scripts, etc. Thanks to such a
directory it is not important where the files are actually installed, or
if they have a -qt3/4 suffix, and so on. This works for Qt3/4, and it
would work for libqglviewer if there was not a small problem: the name
of the library is independent of Qt3/4 (which is not the case for Qt
itself). I missed that fact when I filed the bug. So proposal (2) does
not work.
About #20:
> I think about putting include files into
> /usr/include/qglviewer-qt3/QGLViewer
> instead of /usr/include/qglviewer-qt3. So, one need to add only
> -I /usr/include/qglviewer-qt3 to compilation options. However it still
> requires some tweaking to get proper .so file for linking.
This solution still requires passing an -I directive and a different -l
argument for both variants ...
As also already pointed out by others, I would change the default to
Qt4. Why?
- libqglviewer upstream has changed the default to Qt4
- Qt4 was released 4 years ago, even big projects like KDE have
transitioned to Qt4 now
- Squeeze is not released now, but in 6-12 months, that is almost 5
years after Qt4 has been released
- a transition for Squeeze+1 would be effective only ~18 months after
Squeeze was released, so roughly 6 years after Qt4 was released
What about the following package layout (I just give the essential
files, no symbolic links, documentation, etc.). Basically it is a
slightly updated version of my proposal (1):
libqglviewer-headers: (could probably be Arch:all)
- /usr/include/QGlViewer/qglviewer.h (and all the other header files)
libqglviewer2:
- /usr/lib/libqglviewer.so.2.3.1
libqglviewer-dev: (depends on libqglviewer-headers)
- /usr/lib/libqglviewer.a
libqglviewer-qt3-2:
- /usr/lib/libqglviewer-qt3.so.2.3.1
libqglviewer-qt3-dev: (depends on libqglviewer-headers)
- /usr/lib/libqglviewer-qt3.a
This approach has the following advantages:
- the Qt4 variant is usable without any changes (compared with an
standard install of the upstream sources)
- examples should build without further modifications against the Qt4
variant
- same for other packages depending on the Qt4 variant
- If one still wants to use the Qt3 variant, one has to make only
minimal changes (just the library name, the headers are shared)
- The library SONAME for the Qt4 variant does not deviate from the
upstream SONAME
Disadvantages:
- a transition for squeeze (but there are no packages in Debian yet
depending on libqglviewer -- apart from my cgal package)
- the packaging is "asymmetric" in some sense (but I think it ok to
"prefer" the upstream default and newer Qt4 variant in some way)
I'm not sure whether transitional packages
libqglviewer-qt4-dev => libqglviewer-dev
libqglviewer-qt4-2 => libqglviewer2
are needed.
By the way: what purpose serve the two non-*.h files in
/usr/include/qglviewer-qt{3,4}?
Unless I missed something: the examples themselves are not available in
the binary packages, only the HTML for them. Could add them to the -dev
packages (as tarball in /usr/share/doc/<packagename>)?
Joachim
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
