On 2022-04-18, David Kalnischkies wrote: > On Sun, Apr 17, 2022 at 06:50:19PM -0700, Vagrant Cascadian wrote: >> This also allows building functional apt packages with a smaller >> dependency chain, so might help with bootstrapping efforts too! > > Bootstrap usually doesn't care about arch:all packages, so that argument > doesn't work that well here. Fair. > I would even say it works against you: *raised eyebrows* :) >> I thought docbook* and xsltproc could also be excluded from the >> Build-Depends, but that triggered some other build failures. > > They (alongside po4a) are used to build the manpages which we ship in > our arch:any packages (we could go with apt-common, but while that > saves mirror space, it could waste system space as you now have manpages > installed for things you haven't installed… or we go with multiple > apt-common packages which increases complexity and overhead… so far we > haven't gone down this road as it seems not very beneficial in the end). Thanks for the explanation, that makes sense! > We certainly could improve support for nodoc (upon your patch) by not > building the manpages in this profile which could indeed help boot- > strapping (although they never asked so far, which I am somewhat > surprised now to be honest) – Heh. Either way, works for me. > but it would also end up changing the contents of every package and > hence spoil src:apt reproducibility in that it will be reproducible on > paper, but nobody can actually use the result. I'm fine with that for my purposes, as it arguably a build profile is an input to the build process; we don't expect packages built with a different build profile to come out identical, especially the nodoc profile which explicitly allows for differences in packages. If you do two builds with "nodoc" and they come out identical, that works for my use-case, with or without the man pages. Though I guess then it's not so much "nodoc" as "lessdoc" which is less compelling as a generic build profile name. :) >> Of course, ideally building documentation reproducibly would be very >> nice as well, so it would be good to eventually fix the underlying >> issues in doxygen: >> >> https://tests.reproducible-builds.org/debian/issues/unstable/nondeterminstic_todo_identifiers_in_documentation_generated_by_doxygen_issue.html >> https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_ordering_in_documentation_generated_by_doxygen_issue.html > > It seems like hard issue(s) to solve and I am certainly not up to work > on this, Indeed, which is why I am exploring the "nodoc" route. > but there seem not too many effected, so perhaps its worthwhile > to go the route of a nodoxygen (or pkg.*.nodoxygen) profile instead as > it would mean less variation and e.g. a reproducible binary apt package > would at least mean something as everyone has that variant installed. Thanks, that's an interesting angle, will chew on it a bit! I wanted to explore what we could get out of the existing and somewhat established and broader scope "nodoc" build profile, as there are a few other documentation generation tools with similar reproducibility issues (sphinx comes to mind). > I would at least be happy to beat our build system into omitting just > the doxygen part rather than some (currently with patch) or all > (possible future) docs. Shouldn't be hard (= famous last words). Thanks, if it intrigues and inspires you, go for it, though I'd hate to send you too deep down that rabbit hole otherwise... I was mostly just looking at smallish changes that would give some nominal level of ability to programatically check for reproducibility in apt (and a few other remaining essential/required/build-essential packages) even if we can't reproducibly build the documentation at the moment. One can manually see that the arch:any packages for apt are generally reproducible in bookworm already: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/apt.html Amoung other plans, I'd hope to have stats at the binary package level rather than just source package level on tests.r-b.org someday... but not in the immediate future. Thanks for the quick response and good thoughts! live well, vagrant
Attachment:
signature.asc
Description: PGP signature