sys-fs/udisks-2.7.3 unconditionally depends on dev-util/gtk-doc. Meanwhile the udisks-2.7.3.ebuild contains the following configure option: src_configure() { ... --disable-gtk-doc ... So is gtk-doc really required by udisks? And even if it is, shouldn't it be optional via the 'doc' USE-flag?
Maybe what is actually needed is dev-util/gtk-doc-am. dev-util/gtk-doc-am provides /usr/share/aclocal/gtk-doc.m4 with GTK_DOC_CHECK macro, which is used by configure.ac of sys-fs/udisks-2.7.3.
gtk-doc-am should always be build depended on, even if not running eautoreconf. It provides gtkdoc-rebase, which will update the documentation to use local links where possible (quick search&replace style, no rebuilding of gtk-docs found in the tarball) gtk-doc is only necessary if using --enable-gtk-doc, which on autotools dist based tarballs is usually never needed, because they ship with pre-built gtk-docs. This changes with meson, as it has no support for such a gtk-doc pre-generation into tarball (at least yet).
Created attachment 509520 [details, diff] A quick and dirty attempt to get rid of the gtk-doc dependency. I stumbled about this as well; And as any superfluous dependency on my systems annoys me - moreso, if they fail tests as gtk-doc does - here's a quick and dirty ebuild patch against v2.7.4 to get rid of it. If a simple conditional patch instead of the sed statements raises the chance to get this into the Gentoo repository, I' fine to provide it, so please drop a line.
I'd also like to see this made (or return to?) optional. I don't run gnome on my system, and aside from gtk-doc itself this pulls in several additional packages that are otherwise unneeded. Understand this is likely considered low priority. Just wanted to make sure other use cases are considered. Thanks.
Without gtk-doc, udisks eautoreconf would fail with automake-1.15: error: cannot open < gtk-doc.make: No such file or directory This is not an issue for other packages, because their tarballs DIST gtk-doc.make. udisks tarball that we use doesn't have this, as it's from a GitHub tag download, instead of releases. If we'd use proper upstream tarballs, then this wouldn't be an issue, as SRC_URI="https://github.com/storaged-project/udisks/releases/download/${P}/${P}.tar.bz2" instead of SRC_URI="https://github.com/storaged-project/${PN}/archive/${P}.tar.gz" would use a properly disted tarball, instead of git tag, and that one does include gtk-doc.make just fine, thus gtk-doc-am dep would be sufficient. Because the archive download is .tar.gz, while the releases are .tar.bz2, there would be no checksum changes either, when doing the change to existing 2.7.5 ebuild. I don't know why udisks ebuild uses git tag GH download instead of release tarballs.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=039e3df6877fa36d29593ff80bf8af9b3c86b0ab commit 039e3df6877fa36d29593ff80bf8af9b3c86b0ab Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2017-12-19 17:28:32 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2017-12-19 17:29:29 +0000 sys-fs/udisks: use disted release tarball, avoids full gtk-doc dependency Closes: https://bugs.gentoo.org/631822 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-fs/udisks/Manifest | 2 +- sys-fs/udisks/udisks-2.7.5.ebuild | 6 ++---- 2 files changed, 3 insertions(+), 5 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33f978e06e7c9b04b1aab3d0d7f15a71205294ea commit 33f978e06e7c9b04b1aab3d0d7f15a71205294ea Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2017-12-19 19:20:54 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2017-12-19 19:30:52 +0000 sys-fs/udisks: remove now unnecessary eautoreconf call Looks like eautoreconf was only needed due to not using a disted tarball. Bug: https://bugs.gentoo.org/631822 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-fs/udisks/udisks-2.7.5.ebuild | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)}
