On 27/06/16 17:44, Matthias Clasen wrote: > Historically, one reason for including generated documentation in > tarballs was that the generated docs depend on details of the build > architecture, and timestamps, etc. So, generating the docs multiple > times for various architectures in build systems would generate > multilib conflicts.
In Debian we deal with this by doing a separate build pass on the autobuilders for "Architecture: all" packages (the dpkg equivalent of RPM's noarch), including documentation. Ubuntu deals with this slightly differently by nominating one architecture to be special (I think it might still be 32-bit x86, which was the most important architecture when Ubuntu started?), and only building the Architecture: all packages on that autobuilder, not the others. Reproducible builds <https://reproducible-builds.org/> also mitigate this by either eliminating documentation timestamps, or setting them to the date at which the *source code* changed (for example in Debian/Ubuntu we use the date in the latest debian/changelog entry). Rebuilding everything, including Autotools-generated files (Makefile.in, configure) and documentation, is widely considered to be best-practice for Debian packages. Taking any generated content from tarballs and shipping it in the binary packages would mean we aren't actually compiling from the source code (preferred form for modification), which would mean we don't really know whether our system *can* do that: this becomes a practical problem as soon as we want to make a change to the source of those generated files. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list