GNOME Bugzilla – Bug 790840
Cmake: hard-coded LIBDIR path
Last modified: 2018-06-30 00:01:08 UTC
When Gnucash 2.7.1 is built using Cmake some private libraries are installed to "/usr/lib". On Debian it is a policy violation as "/usr/lib" is for shared libraries only (let alone that path should include multi-arch qualifier e.g. "/usr/lib/x86_64-linux-gnu"). With Automake we used to pass "--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/gnucash" option to `configure` but Cmake appears to hard-code LIBDIR path as "${CMAKE_INSTALL_PREFIX}/lib". Could it be made more flexible please? Thanks.
Please try the new http://downloads.sourceforge.net/gnucash/Development/gnucash-2.7.2.tar.bz2 uploaded a few moments ago. It uses CMake's GNUInstallDirs which for me fixes both this and bug 790841 with no need for passing anything but -DCMAKE_INSTALL_PREFIX=/usr.
Already tried and it is no different from 2.7.1 in regards to this problem. Do we need to use any special Cmake parameters?
Please make sure that the line "INCLUDE GNUInstallDirs" is in the top-level CMakeLists.txt. If it's not there it's the one from two days ago and you need to re-download it. Maybe I should have re-named it gnucash-2.7.2-3.tar.bz2 or something...
OMG that's it, 52 different files between 2.7.2/2017-11-25 and 2.7.2/2017-11-28 tarballs... So much grief, frustration and wasted time... Please don't update tarballs silently. It make downstream work so much harder and it would have been order of magnitude worse if I had uploaded previous tarball to Debian... Tarballs should be immutable. Also please use only semantic versioning and avoid '-' in versions because "minus" character separates upstream version from package revision. Read more in Debian Upstream Guide: https://wiki.debian.org/UpstreamGuide --- While location of "etc" has been fixed, latest tarball exhibit another problem: directories named "}" and "}exec" in "/usr" after build. The following files can be found in "}" after build: * gnc-fq-check * gnc-fq-dump * gnc-fq-helper * gnc-fq-update "}exec" contains the following: * gnucash/overrides/gnucash-env * gnucash/overrides/gnucash-make-guids Thanks.
Another problem is that python files are installed into "/usr/local" instead of "/usr"...
> Please don't update tarballs silently. Note the URL: The tarball is in Development/, not Gnucash (unstable)/2.7.2. It's a private tarball for your convenience only. I would have made it an attachment here but it's too big. I wouldn't ever change a release tarball after announcing the release. For that reason versioning is immaterial and we're not going to change the versioning system for actual releases. > Read more in Debian Upstream Guide Cluebat: GnuCash is carried by pretty much every Linux distribution except RHEL/Centos and most BSD flavors as well. We're not going to customize our practices for Debian. Thanks for the list of misplaced files. The first two batches are typos and easily fixed. Python may take a little more effort.
I've uploaded https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dmitry_number_3.tar.bz2/download with fixes for the errors you noticed and a few others as well.
> GnuCash is carried by pretty much every Linux distribution Of course. And most of them are Debian derivatives (more than 100). Debian is an upstream for most of those distributions. Combined Debian ecosystem most certainly represent majority of GnuCash users -- strong reasons to care for Debian at least a little more that for other distros. > We're not going to customize our practices for Debian. Did you actually care to read the document? There are no distribution specific recommendations there (none that I can recall anyway). It is just a summary of good practices that pretty much all distributions are following (or should follow) such as respecting FHS, XDG directories, varsioning conventions etc. As Debian upstream you are mostly required to follow well established practices and common sense. :) Updated tarball is much better. Thank you. There are only few spills left in "/usr/libexec" as mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=790845#c13
Thanks, John. I tried 2.7.2_just_for_dmitry_number_5 and it is almost good except for the very problem reported here. Is there a way to override LIBDIR and send all private libraries to "/usr/lib/gnucash" instead of "usr/lib/x86_64-linux-gnu"? The following private libraries should not be exposed system-wide: ~~~~ libgnc-backend-sql.so libgnc-backend-xml-utils.so libgnc-core-utils-python.so libgnc-core-utils.so libgnc-gnome.so libgnc-module.so libgwengui-gtk3.so ~~~~ Thanks.
You can set -DCMAKE_INSTALL_LIBDIR=/usr/lib/gnucash, which will install /usr/lib/gnucash/libgnc-*.so and /usr/lib/gnucash/gnucash/libgncmod-*.so. It will also put libgwengui-gtk3.so in /usr/lib/gnucash for now. That's actually part of Gwenhywfar so when Debian updates to 4.18 it will be in /usr/lib/x86_64-linux-gnu again. I do need to get CMake to detect that and not build it in GnuCash if it's already available. FWIW the default location of libgnc-*.so has always been in libdir. Have you been passing --libdir in your automake builds to change that?
libdir has indeed been the default for all of the libgnc-* libraries for a very long time. But I agree they shouldn't be there. On the other hand I would like to keep the clear distinction between these ordinary shared libraries and the libraries managed via gnc-module. So I would propose to move the libgncmod-* libraries to pkglibdir/modules and the other libgnc-* modules to pkglibdir. While we're on the topic I will also point out libgnc-backend-* are two special cases as well. Both are dynamically loaded by gnucash at runtime using dlopen rather than via the standard system linking mechanism. So they are more like plugins as well rather than standard shared libraries. I have been considering moving them into their own separate subdirectory as well while restructuring the source directories. I didn't do so then as I didn't want to mix yet another move in an already big change. I forgot afterwards, but perhaps this is a good time to do so. Although they are not loaded by gnc-module as the other modules, we may add them in the same directory as their naming convention clearly distinguishes them.
Thanks for the hint about "CMAKE_INSTALL_LIBDIR" -- I could never get the right CMAKE variable from the first try... This addresses my concerns about installation directory. Indeed we were building with "--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/gnucash" all the time...
Can we close this now?
Yes of course, unless you want to keep it opened to track Geert's suggestions regarding location of plugins... Thank you.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=790840. Please update any external references or bookmarks.