After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653323 - librsvg-2.34.0 rdepends on gtk+-3 automagically
librsvg-2.34.0 rdepends on gtk+-3 automagically
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
: 396722 712693 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-06-24 10:48 UTC by Pacho Ramos
Modified: 2017-12-13 17:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
1.patch (1.38 KB, patch)
2011-06-24 10:48 UTC, Pacho Ramos
none Details | Review
proposed patch for 2.36.0 (1.96 KB, patch)
2012-04-12 00:43 UTC, Alexandre Rostovtsev
none Details | Review

Description Pacho Ramos 2011-06-24 10:48:56 UTC
Created attachment 190569 [details] [review]
1.patch

As reported downstream at:
http://bugs.gentoo.org/show_bug.cgi?id=371290

librsvg automagically depends on gtk+-3 when it's present in the system, we would like to be able to set what gtk+ to use with "--with-gtk=2.0|3.0|all" switch. Our doubts are about how to properly handle building supporting both versions when user wants to.

Attached patch could be a start point, but would be nice to get upstream suggestions also. Thanks a lot
Comment 1 Pacho Ramos 2011-09-09 20:03:24 UTC
Any news here? Thanks
Comment 2 Alexandre Rostovtsev 2012-04-12 00:43:03 UTC
Created attachment 211889 [details] [review]
proposed patch for 2.36.0

A similar issue exists in librsvg-2.36.0: rsvg-view-3 is always built if gtk3 is detected; there is no way to explicitly disable rsvg-view-3 when creating a package for a gtk2-only deployment when using a build machine that has gtk3 installed.

The attached patch adds a --disable-rsvg-view configure switch to do so. Please review.
Comment 3 Christian Persch 2012-04-17 22:04:00 UTC
I don't see why this is necessary. If you have gtk3-devel pkg installed, it builds rsvg-view; but you can just simply not put that into your package and thus avoid the gtk3 dep on it...
Comment 4 Antoine Jacoutot 2012-12-28 09:45:08 UTC
Hi.

I'm coming back to this old bug. I think it's be worth doing what gentoo does and making the compilation of rsvg-view optional with a configure switch. Sure, one does not have to include it in the package; but when running package bulk builds, packages are often added/removed and in the case of librsvg the following happens quite often for me:
* librsvg is schedule to build
* gtk+3 is detected at configure time
* while librsvg is being built, the gtk+3 package may end up being removed because it is not registered as a dependency
* librsvg build fails because it detected gtk+3 at configure time but it got removed in the middle of the librsvg compilation

Sure I can enforce a build-only dependency on gtk+3 for librsvg but this seems overkill.

I don't think it costs much to add this configure check, preserving the default behavior of if gtk+3 is found, then build rsvg-view.
As far as I am concerned, it would means less local patches for me... FWIW.
Comment 5 Antoine Jacoutot 2013-04-04 19:07:11 UTC
(In reply to comment #3)
> I don't see why this is necessary. If you have gtk3-devel pkg installed, it
> builds rsvg-view; but you can just simply not put that into your package and
> thus avoid the gtk3 dep on it...

Hi Christian.

Would it be really an issue to have this patch committed?
That would at least help OpenBSD and Gentoo maintainers...

I can push it, but since you had some reservations.
Thank you.
Comment 6 Robert Roth 2015-01-17 07:43:44 UTC
*** Bug 396722 has been marked as a duplicate of this bug. ***
Comment 7 Robert Roth 2015-01-17 07:43:56 UTC
*** Bug 712693 has been marked as a duplicate of this bug. ***
Comment 8 Robert Roth 2015-01-17 07:46:07 UTC
There's another patch proposed in duplicate bug 712693.
Comment 9 Pacho Ramos 2015-02-18 11:17:30 UTC
can this patch be finally pushed?
https://bugzilla.gnome.org/show_bug.cgi?id=712693#c3
Comment 10 Johannes Dewender 2015-07-23 10:58:07 UTC
Seriously, why isn't this patch included?

Several distributions have user repositories for source packages, creating binary packages locally.
Having the header files installed does not necessarily mean that the libraries (for the current architecture) are also installed. (like when building 32 bit packages, having gtk3 installed, but no 32 bit gtk3)

Current issue at the lib32 package for Arch Linux User Repository (AUR):
https://aur.archlinux.org/packages/lib32-librsvg/
Comment 11 Pacho Ramos 2016-01-10 18:11:49 UTC
ping
Comment 12 Pacho Ramos 2016-07-02 12:43:42 UTC
Please, take a look on this if possible
Comment 13 GNOME Infrastructure Team 2017-12-13 17:48:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/53.