Hello, It seems possible to split the installation of the HTML reference manual from media-sound/audacity (media-sound/audacity[doc]). A dedicated ebuild for the documentation may save time when the reference manual is (un)merged, since media-sound/audacity won't be recompiled. I'll open a PR to try this concept out.
Not sure this is worthwhile. We already need more help with maintaining audacity, and adding another thing to bump at the same time isn't ideal. Is it really that common for people to toggle USE=+/-doc on audacity? Besides, then we're trading one problem for another, where people who want audacity docs have to manually add it to world rather than just enabling USE=doc (as pure runtime use flags are forbidden).
I saw that there are different app-doc/* packages, like app-doc/gimp-help and app-doc/gnucash-docs, to install reference manuals. IMHO, for some packages that require a relative long time to compile it could be helpful to install HTML pages separately from the main package (i.e. without enabling a 'doc' use flag and then recompile the main ebuild), an example of this would be sys-devel/llvm API reference pages (that also take quite some HD space). I think that we are dealing with trade-offs between a stand-alone documentation ebuild and a 'doc' use flag in the main package. In some cases, manual pages can be installed even without installing the main package first, and this may be thought as more freedom of choice (when doing a port from a version to another some may want to install the latest library, its API pages, and a previous API version). Splitting media-sound/audacity[doc] from the main ebuild seems to be trivial. Right now I'm trying a new media-sound/audacity-3.3.3.ebuild (version bump) before opening a PR to also demonstrate the concept explained above. Mine is just a proposal, once the PRs are ready, trying out the stand-alone app-doc and version bump ebuilds should not take too much, and merging the PRs isn't mandatory as I prepared them as a proof of concept.
I don't personally see the value in it, but that doesn't mean I object. I'm happy to merge it if you're willing to look after audacity + audacity-docs going forward as a proxied maintainer.
If the stand-alone Audacity's documentation ebuild could be of any aid to the community, I'll happily help in my capacity to contribute as a proxied maintainer. Are there any special needs/configurations for a testing environment (chroot, ebuildtester, etc.)?
(In reply to mehw from comment #4) > If the stand-alone Audacity's documentation ebuild could be of any aid to > the community, I'll happily help in my capacity to contribute as a proxied > maintainer. > Great! > Are there any special needs/configurations for a testing environment > (chroot, ebuildtester, etc.)? Take a look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e04e0ee75ec9a30fada6d3670283804c24d47712 commit e04e0ee75ec9a30fada6d3670283804c24d47712 Author: Matthew White <mehw.is.me@inventati.org> AuthorDate: 2023-08-01 14:41:23 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-23 08:29:09 +0000 app-doc/audacity: HTML reference manual for Audacity Closes: https://bugs.gentoo.org/911561 Package-Manager: portage-3.0.49-r1 Signed-off-by: Matthew White <mehw.is.me@inventati.org> Closes: https://github.com/gentoo/gentoo/pull/32128 Signed-off-by: Sam James <sam@gentoo.org> app-doc/audacity/Manifest | 2 ++ app-doc/audacity/audacity-3.3.3.ebuild | 26 ++++++++++++++++++++++++++ app-doc/audacity/audacity-3.4.2.ebuild | 26 ++++++++++++++++++++++++++ app-doc/audacity/audacity-9999.ebuild | 26 ++++++++++++++++++++++++++ app-doc/audacity/metadata.xml | 19 +++++++++++++++++++ 5 files changed, 99 insertions(+)
