Hi, we the recent update of zathura to 0.5.2-r2 it is required to install sphinx also: [ebuild N ] dev-python/alabaster-0.7.12-r1 PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/imagesize-1.4.1 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/snowballstemmer-2.2.0-r1 PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/pytz-2022.7 PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/Babel-2.11.0 USE="-doc -test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-applehelp-1.0.3 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-devhelp-1.0.2-r1 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-jsmath-1.0.1-r2 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-htmlhelp-2.0.0-r1 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-serializinghtml-1.1.5-r1 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinxcontrib-qthelp-1.0.3-r1 USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild N ] dev-python/sphinx-6.1.3 USE="-doc -latex -test" PYTHON_TARGETS="python3_11 -pypy3 -python3_8 -python3_9 -python3_10" [ebuild U ] app-text/zathura-0.5.2-r2 [0.5.2-r1] USE="seccomp -sqlite -synctex -test (-doc%)" Is it possible to readd the doc use flag. Thanks Reproducible: Always
The zathura's build system uses sphinx to generate manpages. The policy in gentoo is to always install man pages unconditionally, it was removed because of bug 837710. You might want to check with zathura upstream if they are willing to switch to something lighter like rst2man, How much of an problem is the existence4 of sphinx for you there? We could ignore sphinx and use rst2man.py and doman, however I am not sure if I want to take this maintenance burden on myself just to drop this dependency. It would be another story of sphinx were difficult to build.
Hi, thanks for your reply. I do not think is a huge undertaking to install sphinx. I am a bit annoyed by the installation of another 10 dependencies for the documentation that I will never use.
From the official README (https://git.pwmt.org/pwmt/zathura/-/blob/develop/README.md?plain=1#L38): Note that `Sphinx` is needed to build the manpages. If it is not installed, the man pages won't be built. That's the behaviour that I would like to have.
There's rst2man.py but it will then require dev-python/docutils instead of sphinx. The manpages are mandatory, so we need to choose our poison, sphinx or hack with dev-python/docutils
I have just created a new build basically reverting latest commit: # Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 inherit meson virtualx xdg DESCRIPTION="A highly customizable and functional document viewer" HOMEPAGE="https://pwmt.org/projects/zathura/" if [[ ${PV} == *9999 ]]; then inherit git-r3 EGIT_REPO_URI="https://git.pwmt.org/pwmt/${PN}.git" EGIT_BRANCH="develop" else SRC_URI="https://github.com/pwmt/zathura/archive/${PV}.tar.gz -> ${P}.tar.gz" KEYWORDS="~amd64 ~arm ~riscv ~x86 ~amd64-linux ~x86-linux" fi LICENSE="ZLIB" SLOT="0/$(ver_cut 1-2)" IUSE="doc seccomp sqlite synctex test" RESTRICT="!test? ( test )" DEPEND=">=dev-libs/girara-0.3.7 >=dev-libs/glib-2.50:2 >=sys-devel/gettext-0.19.8 x11-libs/cairo >=x11-libs/gtk+-3.22:3 sys-apps/file seccomp? ( sys-libs/libseccomp ) sqlite? ( >=dev-db/sqlite-3.5.9:3 ) synctex? ( app-text/texlive-core )" RDEPEND="${DEPEND}" BDEPEND="doc? ( dev-python/sphinx ) test? ( dev-libs/appstream-glib dev-libs/check ) virtual/pkgconfig" PATCHES=( "${FILESDIR}"/zathura-disable-seccomp-tests.patch ) src_configure() { local emesonargs=( -Dconvert-icon=disabled -Dmanpages=$(usex doc enabled disabled) -Dseccomp=$(usex seccomp enabled disabled) -Dsqlite=$(usex sqlite enabled disabled) -Dsynctex=$(usex synctex enabled disabled) ) meson_src_configure } src_test() { virtx meson_src_test } It successful compile and install.
I am not entirely sure what's the message you'd like to pass here by showing that you reverted the change? I see nothing to fix here really. The sphinx is required by upstream to build manpages, that are mandatory in Gentoo, alternative would be to hack it with dev-python/docutils's rst2man but then again, it would require dev-python/docutils that it does not right now and another user could create a bug here, that it depends on docutils and they don't like it, with another option to build them separately and distribute as additional distfiles from dev.gentoo.org. Neither of those looks particularly appealing to me, either another dependency instead of sphinx or additional work with every version bump. If sphinx were to be abandon upstream, stopped supporting new Python releases or become horrendously problematic to build, I'd go with one of the alternatives, but this is not how it looks for today. I will go ahead and close it as WONTFIX, feel free to reopen this one, or create new one in case the sphinx becomes an actual blocker in the future, something more than just that it depends on sphinx that you'd rather not have.
*** Bug 891123 has been marked as a duplicate of this bug. ***
(In reply to Piotr Karbowski from comment #1) > The policy in gentoo is to always install man pages unconditionally, The full policy is this (see QA policy guide PG 0305 and bug 689684): | Packages must not disable installing manpages via USE flags (e.g. | ``USE=man`` or ``USE=doc``). If upstream does not ship prebuilt | manpages and building them requires additional dependencies, | the maintainer should build them and ship along with the package.
Reopening as zathura ebuild will soon ship pregenerated man pages.
(In reply to Ulrich Müller from comment #8) > (In reply to Piotr Karbowski from comment #1) > > The policy in gentoo is to always install man pages unconditionally, > > The full policy is this (see QA policy guide PG 0305 and bug 689684): > > | Packages must not disable installing manpages via USE flags (e.g. > | ``USE=man`` or ``USE=doc``). If upstream does not ship prebuilt > | manpages and building them requires additional dependencies, > | the maintainer should build them and ship along with the package. Thanks for clarification. I think it would help much if we could change the 'should' into 'must' or 'is expected'. While there might be borderline cases where it is not feasible to pregenerate them, 'should' looks to me more like hint, or a suggestion rather than policy to follow, though I am not native English speaker, which then leaves us with debates like here. Not a fan of 'pick one' and then getting bugs 'you picked the wrong one' kind of solution. There will always be exceptions though. Whats are your thoughts about it?
Well the truth is not every maintainer may be as thorough as Piotr (and also a developer), so we are lucky in this case. In other cases a maintainer may (and for a good reason) ask themselves why they are putting up with this for absolutely no good reason. There is neither a disproportionate amount of false bugreports where people have overlooked USE=man and are complaining about missing manpages. Nor is there a systematic contradiction, such as for every binary x there must be a corresponding `man x`. Nor have I ever heard anyone complain about being able to configure the generation of manpages. Demanding that "manpages MUST be installed by every package" is just a completely futile endeavour which causes disagreements and problems all over the place and benefits absolutely no one in practice.
I think the policy is fine in what it is aiming to do just I found the actual wording a bit unfortunate, and I much prefer to always have manpages installed, those can be skipped on end-user side with FEATURES noman and noinfo if info pages are there too. The only problem that I see here is the policy that does not quite decide it, but highly suggest, leading to very fragmented implementation of it, existence of 'man' global flag does not help here either. We also do not actually have this policy in devmanual, or I just failed hard to find it there. If we could rephrase the policy so it does not leave room for misinterpretation whatever it is 'should' or 'must', add the policy into devmanual and actually go with tracker bug to get rid of the man USE flag that would solve all the potential problems I believe, and maintainers would become aware that the manpages needs to be pre-generated if the sources does not ship with it in such shape. This however needs to be facilitated by the QA team as this is within their area.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff8925541b7344eef7cf9ef73d29a88cdab45038 commit ff8925541b7344eef7cf9ef73d29a88cdab45038 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2023-01-21 15:26:35 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2023-01-21 15:38:37 +0000 app-text/zathura: 0.5.2-r3: use prebuilt manpages. This change aligns zathura to the installed-files policy changes published on 2023-01-18 Closes: https://bugs.gentoo.org/890589 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> app-text/zathura/Manifest | 1 + .../{zathura-0.5.2-r2.ebuild => zathura-0.5.2-r3.ebuild} | 15 ++++++++++++--- 2 files changed, 13 insertions(+), 3 deletions(-)
(In reply to Larry the Git Cow from comment #13) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff8925541b7344eef7cf9ef73d29a88cdab45038 Thank you.
btw I have carried a patch https://cgit.alxu.ca/gentoo-overlay.git/tree/app-text/zathura/files/zathura-docutils.patch in my overlay for ~15 months now, fairly minimal changes are needed to support docutils. the output is not exactly identical, e.g. it doesn't have the version, but the version was wrong anyways.
(In reply to Ulrich Müller from comment #14) > (In reply to Larry the Git Cow from comment #13) > > The bug has been closed via the following commit(s): > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff8925541b7344eef7cf9ef73d29a88cdab45038 > > Thank you. Anytime. (In reply to Alex Xu (Hello71) from comment #15) > btw I have carried a patch > https://cgit.alxu.ca/gentoo-overlay.git/tree/app-text/zathura/files/zathura- > docutils.patch in my overlay for ~15 months now, fairly minimal changes are > needed to support docutils. the output is not exactly identical, e.g. it > doesn't have the version, but the version was wrong anyways. That would still require docutils which it currently does not, people could be rightfully upset that it pulls it in, I underestimated the effect harddep on sphinx had, so I rather not wander in this direction. I don't mind shipping them prebuilt, perhaps would be best to poke upstream to actually provide proper release tarballs, I mailed Sebastian Ramacher asking for this feature, until he decide to provide them, I will just pregenerate them.
dev-python/docutils is more frequently used for documentation, though, and - contrary to Sphinx, which I rather see as a form of "Javadoc"ish sourcecode documenter - a bit of a modern replacement to groff, texinfo, etc. Nowadays with python everywhere people often have it already. If the QA 0305 policy is not withdrawn, you will sooner or later find people complaining about docutils dependencies anyway, personally I have it on pipewire, mpv, libdrm and a few gtkish libraries. All this mess wouldn't exist and no bugs would be filed if it weren't for 0305...
Well and thanks, of course (but that should go without saying)
