Bug#522659: updated proposal
Joachim Reichel wrote : 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 fully second this layout proposal. Let me know if there is anything I can do in the main sources to help you in the packaging process. -- Gilles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#277196: QGLViewer debian package name
Hello, Artur just pointed this thread to me. I discover the debian's insights. First, I would like to say that I would really like to provide a Debian package for the libQGLViewer library. The name conflict with the Tuebingen library is too bad. I discovered it when I released this (originally internal) library on the web, and it was too late to change it. It created many confusions and I regret it. That's why I suggest lib3DViewer as a Debian package name. I will not change the .so name nor the rpm package name (since that's how it is known in the Mandriva and Fedora distributions). However, I may extend the library to other widget toolkits in the future, making the Qt's 'Q' in 'QGL' less appropriate. I may then rename the whole thing lib3DViewer. The tar numbering scheme will be fixed for version 2.0 (expected by the end of the month). Feel free to contact me if there are any other issues. -- Gilles Debunne. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277196: QGLViewer debian package name
You don't need to provide it yourself, thats what we debian developers are here for, That's what I meant, I should have written provide support for Debian packaging. If you want, you can add the debian packaging information (a debian subdir with some text files in it) to your main tree. This would allow everybody to build .debs on its own, especially as it is of course too late to add it to sarge now. I'd be glad to do so. Just tell me which files/directories to add (that is probably what artur already did in his package). Which toolkits do you plan to support? wxWidgets to start with. But once I managed to separate 3D and Qt, the port to other toolkits (FOX, glut,...) should be easy (if you know any other by the way). Thanks, -- Gilles. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277196: QGLViewer debian package name
gtk comes in mind, it has at least two gl widgets of its own. Sure I guess if you support qt/wx and gtk you have pretty much everything covered gui-wise. Will the 2.0 release alreadyt be separated? I can look at the gtk porting then if you want to. No. The port to other widgets needs further investigations. I use Qt specific classes (QString, QDom...) everywhere. There are probably substitutes, but I want to maintain a single code tree. typedef or wrapper classes should do. Then what about the doc ? And the examples ? Not that easy. I need to look at it, to see what it really represents in terms of work. BTW, shall I still reply to bugs.debian.org ? -- Gilles. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
