GNOME Bugzilla – Bug 667127
Compilation of Gimp 2.7.4 with ATK 1.32.0 ?
Last modified: 2012-01-08 17:39:42 UTC
Hello! I have recently bumped Gimp to 2.7.4 in Gentoo and some folks get compile errors if ATK is at version 1.32.0 rather than 2.x (build log at [1] below). Besides a note in the HACKING text file I cannot find anything in Gimp that proves a direct dependency on ATK. So I basically have two questions right now: - Does Gimp 2.7.4 depend on ATK directly? If so in what way? - Can you think of anything preventing the compilation against ATK <2.x ? Thanks in advance for your help! Best, Sebastian [1] https://bugs.gentoo.org/attachment.cgi?id=297597&action=edit
We do not require ATK and do not use ATK, it's pulled in via GTK+ and chokes on G_CONST_RETURN which is deprecated in GLib. We should probably simply add a dependency on ATK => 2.2.0 to work around this problem.
FYI users have reported this patch to work around the problem: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-gfx/gimp/files/gimp-2.7.4-no-deprecation.patch?revision=1.1 To my understanding you guys have the deprecation stuff to prevent yourself from using deprecated functions, which I consider a good thing. If ATK is not a real dependency of Gimp, maybe it should not be added as such. What do you think about a new configure option --disable-deprecration, instead?
Updating to a recent version of ATK is still the right fix. We generally don't offer configure switches to build against old versions of libraries, so we should depend on a recent ATK, even if we just implicitly use its headers via GTK+.
That actually works against my interest as there are Gentoo users who seem to prefer sticking to ATK 1.32, see [1]. If you add a check for an implicit dependency I have to choose between forcing these users to use ATK 2.x (without actual need to) or patch the upcoming check against ATK 2.x out downstream. Either is worse than status quo. So I'm hoping for your support to not make things worse. [1] https://bugs.gentoo.org/show_bug.cgi?id=395695#c16
After some thought, I've decided to commit a check for atk 2.2 into master. Going forward, maintaining support for atk 1.32 isn't going to happen. It would be going out of our way and the configure.ac file is complicated as-is already. The patch in that gentoo bug simply disables checks, which is pointless. If something is wrong with atk 2.2, please take it up with their developers. The following patch was committed to the master branch: commit d2d5a3db6298a02aa0e539acab0ac718f9e4a397 Author: Mukund Sivaraman <muks@banu.com> Date: Sun Jan 8 20:16:45 2012 +0530 build: Check for atk >= 2.2.0 (bug #667127)
I was the one who opened this very bug (as a question) and you "fixed" it by adding a fake dependency, the very approach that I asked you *not* to do and for which I gave transparent and honest reasons. There is even two of you who agree on this. If your plan was to disappoint me, you in fact succeeded.
It's not our job to do what bug reporters say, or to make them happy, but to do what we consider right for gimp.
I assumed cooperation with downstream would be right for Gimp.
(In reply to comment #8) > I assumed cooperation with downstream would be right for Gimp. Yes. We paid attention to what you reported. The fact that a commit went in is due to the issue you reported. However, this is how we decided to resolve it. It is the right approach for GIMP, even though it may not align exactly with your current situation. Unstable versions of GIMP always track the latest branches of most deps anyway. It's reasonable to ask us if we can support an older version of a package. We will check it on a case per case basis and decide what is right for GIMP. However, it is unreasonable to keep on complaining about our position past that point. Whining with words like "cooperation" and "honest reasons" make it sound more than what is happening. Use atk 2.2 as a dependency. If there's something wrong with atk 2.2, bug its developers about it.
(In reply to comment #9) > However, it is unreasonable to keep on complaining about our position past that > point. Whining with words like "cooperation" and "honest reasons" make it sound > more than what is happening. Your decision goes against me despite the fact that without me you wouldn't even know about this "issue". How is this not about cooperation or lack of? I am not whining. In fact I am angry. > Use atk 2.2 as a dependency. If there's something wrong with atk 2.2, bug its > developers about it. I will not force Gentoo users to use ATK 2.2 as long as ATK 1.x is not reported to break things with Gimp.
(In reply to comment #10) > (In reply to comment #9) > > However, it is unreasonable to keep on complaining about our position past that > > point. Whining with words like "cooperation" and "honest reasons" make it sound > > more than what is happening. > > Your decision goes against me despite the fact that without me you wouldn't > even know about this "issue". How is this not about cooperation or lack of? In fact we already knew about this and were going to fix it anyway.
(In reply to comment #10) > (In reply to comment #9) > > Use atk 2.2 as a dependency. If there's something wrong with atk 2.2, bug its > > developers about it. > > I will not force Gentoo users to use ATK 2.2 as long as ATK 1.x is not reported > to break things with Gimp. Do you have any reason at all for this? gentoo already has atk 2.2.0 in the tree, and it's not exactly a large package to recompile: Thu Dec 8 00:49:37 2011 >>> dev-libs/atk-2.2.0 merge time: 23 seconds.
Sigh... See, people wont report problems with ATK... They will report bugs against gimp, often directly to us, that we then have to dig through it all just to find out that the reason is an old library that we explicitly do not support... If we ever find out, witch is dubious, since we don't use old libs on purpose.