FS#62468 - [libmypaint] is not detected by gimp build system because of minor-versioning patch
Attached to Project:
Arch Linux
Opened by David Gowers (likytau) - Thursday, 25 April 2019, 11:21 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 10 September 2019, 20:38 GMT
Opened by David Gowers (likytau) - Thursday, 25 April 2019, 11:21 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 10 September 2019, 20:38 GMT
|
Details
Description: Building gimp from git fails at the 'configure'
step because the Arch package specifically patches
libmypaint to install its .pc files as
/usr/lib/pkgconfig/libmypaint{,-gegl}-1.3.pc rather than the
standard /usr/lib/pkgconfig/libmypaint{,-gegl}.pc.
Presumably, this failure also occurs in all other projects which use pkgconfig to get compilation flags for libmypaint. Version: libmypaint 1.3.0-6 Log excerpt: checking for OPENEXR... yes checking for WEBP... yes checking for WEBPMUX... yes checking for WEBPDEMUX... yes checking for LIBHEIF... yes checking for LIBBACKTRACE... no checking for LIBUNWIND... yes checking for LIBMYPAINT... no configure: Eeeeeeeeeeeeeeeeeeeeek! Missing dep: libmypaint >= 1.3.0 checking for MYPAINT_BRUSHES... yes checking for WEBKIT... yes checking for SVG... yes checking for gtk-encode-symbolic-svg... gtk-encode-symbolic-svg checking for POPPLER... yes checking for POPPLER_DATA... yes [...] Error: GIMP configuration failed. - Error: missing dependency libmypaint >= 1.3.0 Further comments: It's possible to skip the detection process and force the result by exporting the variables LIBMYPAINT_CFLAGS=$(pkg-config --cflags 'libmypaint-1.3 >= 1.3.0') and LIBMYPAINT_LIBS (pkg-config --cflags --libs 'libmypaint-1.3 >= 1.3.0') before invoking autogen.sh I'm aware that this is the result of a patch backported from libmypaint 2.x to 1.x, intended to enable the coexistence of (for example) libmypaint 2.0 and libmypaint 2.1. However, given that all active development on libmypaint occurs on the 2.x branch, it is not at all clear why Arch should by default require the user to take special measures to compile with libmypaint 1.x. Upstream GIMP devs regard this as mispackaging, AFAICS (link below). Steps to reproduce: git clone https://gitlab.gnome.org/GNOME/gimp.git cd gimp #autogen.sh automatically runs configure ./autogen.sh Upstream bug report: https://gitlab.gnome.org/GNOME/gimp/issues/3294 |
This task depends upon
Closed by Levente Polyak (anthraxx)
Tuesday, 10 September 2019, 20:38 GMT
Reason for closing: Fixed
Additional comments about closing: 1.4.0-1
Tuesday, 10 September 2019, 20:38 GMT
Reason for closing: Fixed
Additional comments about closing: 1.4.0-1
LIBMYPAINT_CFLAGS=$(pkg-config --cflags 'libmypaint-1.3 >= 1.3.0')
LIBMYPAINT_LIBS=$(pkg-config --cflags --libs 'libmypaint-1.3 >= 1.3.0')
Where's that bug at ?
The upstream code creates libmypaint.pc, but Arch has a specific patch that changes that:
-pkgconfig_DATA = libmypaint.pc
+pkgconfig_DATA = libmypaint-@LIBMYPAINT_API_PLATFORM_VERSION@.pc
The very goal of pkg-config is to have the **same** file names in every distro, but the arch-specific patch deceives that.
I am one of the GIMP devs who worked together with the libmypaint developers to version properly their library, starting the v2. I made an account here specifically for this report. :-)
If the goal of your patch on libmypaint v1 is to make sure that you can install both v1 and v2 side by side, this is unnecessary. If we did things right, there should be no name clash between any of the v1 and v2 files (if you find any, please report to libmypaint). And in particular there is no name clash on the pkg-config file as the new pkg-config files for v2 is correctly named `libmypaint-2.0.pc`.
The reason why the correct versionning was not backported to v1, upstream, and **must not** be backported was exactly the reason why this report is opened today: it breaks existing builds for no good reason. There would have been a reason, say if libmypaint had continued to not properly version its files, hence both v1 and v2 were named `libmypaint.pc`. Fortunately this has not happened, and how the v1 is versionned is just to be seen as a historical anomaly (which is quite common in early history of many software).
Could this patch be removed please? :-)
Thanks!
That is indeed a reasonable explanation/reasoning to get this changed back. In fact, it wasn't done on purpose, at least not from us on the official side. Back than we had some maintainers resign and leaving back gimp, at that specific point in time nobody wanted to maintain it, so eworm and me took on the quest and needed to gain package specific knowledge that was left behind.
While I helped getting gimp to 2.10.0, wich included the requirement of libmypaint, I was in the need to bring libmypaint into the official repo. It was moved over from the non-official userbase maintained AUR where I just did a basic sanity and non-maliciousness check of the build scripts and the patch that was included which we expected to have some reason and it was an official change from the source tree, therefor we just moved it as is into the repos and the real decision to do so was done by the previous (non-official) maintainer. It indeed seems to be a suboptimal decision and we shouldn't have moved that patch along, which became quite clear today and I will stage the removal and rebuild packages :)
gimp
extra/libmypaint
mypaint
And when I pacman -Syu, I get file conflicts, instead of package conflicts=()
$ pkgfile -v /usr/include/libmypaint/mypaint-brush-settings-gen.h
testing/libmypaint 1.4.0-1 /usr/include/libmypaint/mypaint-brush-settings-gen.h
community/mypaint 1.2.1-7 /usr/include/libmypaint/mypaint-brush-settings-gen.h
$ pkgfile -v /usr/include/libmypaint-1.3/mypaint-brush-settings-gen.h
extra/libmypaint 1.3.0-6 /usr/include/libmypaint-1.3/mypaint-brush-settings-gen.h
Read the mypaint pkgconfig file. You'll find it's not a valid pc file (the prefix is /build/…). I guess there's no reason to keep this file, and resolve the conflict with libmypaint by removing it in pkg().