This is indeed a can of worms. A previous discussion on the packaging list[1] concluded that, despite the common practice of packaging Sphinx-generated HTML documentation, there is probably no practical way to do so without running afoul of guidelines about bundled or precompiled JavaScript, CSS, and fonts. Furthermore, Doxygen is just as bad. I’ve been packaging PDF documentation instead, where it’s possible to generate it. This is probably OK, as long as you’re not worried about possible embedded fonts. Since I’m not aware of practical open-source tooling to detect and/or remove these; since a PDF that has essential external dependencies is frustratingly and almost uselessly non-“portable”; and since many LaTeX fonts don’t have OpenType versions that could be packaged as system fonts anyway: if embedded fonts in PDFs were an issue then it seems that packaging PDF files would be effectively banned in practice. I don’t think there’s been a substantial discussion on the matter, though. [1] https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/thread/LLUAURXZVADATHK65HBPPBHKF4EM4UC3/ Further clarity on some of these points would be welcome, although I’m personally *not* eager to put myself at the center of a debate about any of these issues. On Mon, Feb 7, 2022, at 10:51 AM, Petr Menšík wrote: > Hi! > > I maintain bind package, which generates html documentation using sphinx > and sphinx_rtd_theme. I admit this format is quite popular. Once I have > noticed that bind-doc package is quite big. When looking why, I have > found not a small number of static copies were generated by > documentation process. > > If I remember correctly, fonts are allowed to be shipped only by font > packages. Not only sphinx packages ships static copies of javascript > underscore and jquery, but it seems every such package includes also set > of fonts contained in its documentation. > > It leads to interesting situation on RHEL9. It ships fonts in supported > packages, which are not shipped in supported repositories. > > Example: > > dnf repoquery --disablerepo=rhel-CRB --whatprovides > '*/fontawesome-webfont.svg' > > I expect many users would like to serve those packages via web servers > to local networks. Is there way to share static contents in multiple > documentation packages and not break at least most common way to share > /usr/share/doc via web server? > > Note: I have attempted to link static contents to > python3-sphinx_rtd_theme. I symlinked directories js and css in _static > dir. I do NOT recommend anyone to follow my way. This way, I cannot > return real directories with real content into the place. Consider that > a blind way not worth following. > > Is there a good way to reduce duplicated documentation content, when > keeping it reasonably working? Are there helpers for that? It seems even > bodhi-server contains quite big stash of fonts files for example. Many > important packages has them bundled. kernel-doc, rust-doc. Do we want that? > > I have found not a single word about it in font exceptions [1]. Is that > okay? It seems guidelines contradicts common practice on this. > > Regards, > Petr > > 1. > https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/#_exceptions > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemensik@xxxxxxxxxx > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
