Andreas Metzler <ametz...@bebt.de> writes: > Olе Streicher <debian-de...@liska.ath.cx> wrote: >> My question here is now how strict it is to have identical files in >> /usr/share/doc even when build in a different environment (basically, >> both versions are fine here). > > Hello, > It is quite important. If the shared files are not binary identical > then the two versions of the package cannot be installed together, i.e. > multiarch functionality is completely broken.
This design seems a bit broken to me, since one cannot guarantee that a generated file will be bit-identical if generated by different versions of the build environment. >> And, if it is important, how I can ensure that these files are >> identical when the build tools change (causing minimal changes in the >> output). > > I do not think there is a magic bullet. You could edit out the version > number with sed or perl. Or perhaps there are some commandline > switches to get rid of the differences. It is quite usual that a generator writes its own version number into the generated file: help2man does this, sphinx as well (which breaks my packages), but also even (pdf)LaTeX. It seems not a good idea to patch the generated files to revert the changes; especially since I don't know which changes will appear there in future. For example (in my case), sphinx changed an option in the css file from "URL_ROOT: './'," to "URL_ROOT: '',". It is just impossible to check every possible future change of the files in order to patch them out. So these packages are always subject of a failure just when one tries to rebuild them later, contradicting the stabilization of the distribution. > Another option would be to move out the documentation to a separate > arch-independent package. This would be an option, as long as there is not complaint that an arch-independent package should be generated identically regardless of the architecture it is built on :-) Best regards Ole -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vby7v5xg....@news.ole.ath.cx
