Re: arch-dependent files in "Multi-Arch: same" package
Andreas Metzler <ametzler@bebt.de> writes:
> Olе Streicher <debian-devel@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
Reply to: