Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 645036 - gnome-base/librsvg should not depend on vala-common
Summary: gnome-base/librsvg should not depend on vala-common
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-19 17:14 UTC by Cedric Sodhi
Modified: 2020-08-01 21:44 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric Sodhi 2018-01-19 17:14:01 UTC
The remark in the ebuild mentioning that vala-common is required during prepare/configure phase seems no longer to be true. librsvg emerges without errors when vala-common is missing (as tried by using package.provided).
Comment 1 Mart Raudsepp gentoo-dev 2018-01-19 17:29:49 UTC
eautoreconf is called, and that needs the m4 files from vala-common to get the up to date m4 files used from that eautoreconf. We don't want to mess with being lucky with the m4 macros getting picked up by previous aclocal.m4 or however this somehow works for you.

Additionally Makefile.vapigen is included by the Makefiles, and it just happens to be currently done only inside an --enable-vala block and not get executed by make otherwise.

vala-common is a 9kB build-time only package with only m4macros and a Makefile. We won't be micro-managing this and risking until at least there's an eautoreconf that makes use of it. If there wouldn't be an eautoreconf, then maybe we could remove it.
Comment 2 Mart Raudsepp gentoo-dev 2018-01-19 17:52:14 UTC
Further follow-up on IRC made me check things further, and it turns out that librsvg eautoreconf ends up using the vapigen.m4 present in the tarball m4/ subfolder due to the AC_CONFIG_MACRO_DIR([m4]) in configure.ac, and won't use the newer vapigen.m4 shipped by vala-common. Current aclocal doesn't even put it into aclocal.m4, because it finds the m4macros from m4/.
As such the dependency is indeed not needed for m4 needs, and the Makefile.vapigen is only used inside a shell `if` that is only entered with --enable-vala.
I'll consider removing the vala-common upon bump to librsvg-2.40.20 - I think Gilles or someone mentioned it had some new test failures, but I think we want it eventually, in order to have the newest non-rust using version available, should we have to delay librsvg-2.42 for some arches due to rust.
Comment 3 Gilles Dartiguelongue (RETIRED) gentoo-dev 2018-01-25 08:28:31 UTC
librsvg 2.40.20 received lots of bug fixes from 2.41 series but this triggered unittests failures and I suspect this is simply some missing backports but I don't want to break librsvg so this stayed as is due to limited time to recheck the issue.
Comment 4 Larry the Git Cow gentoo-dev 2020-08-01 21:44:13 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=304759386bfcbedbcc940a9938ec56cc1dba69f9

commit 304759386bfcbedbcc940a9938ec56cc1dba69f9
Author:     Mart Raudsepp <leio@gentoo.org>
AuthorDate: 2020-08-01 09:46:02 +0000
Commit:     Mart Raudsepp <leio@gentoo.org>
CommitDate: 2020-08-01 21:43:45 +0000

    gnome-base/librsvg: bump to 2.48.8
    
    Closes: https://bugs.gentoo.org/648990
    Closes: https://bugs.gentoo.org/645036
    Package-Manager: Portage-2.3.84, Repoman-2.3.20
    Signed-off-by: Mart Raudsepp <leio@gentoo.org>

 gnome-base/librsvg/Manifest              |  1 +
 gnome-base/librsvg/librsvg-2.48.8.ebuild | 95 ++++++++++++++++++++++++++++++++
 profiles/arch/arm/armv4/package.mask     |  1 +
 profiles/arch/arm/armv4t/package.mask    |  1 +
 profiles/arch/arm/armv5te/package.mask   |  1 +
 5 files changed, 99 insertions(+)