Francois Gouget <fgou...@free.fr> wrote: > On Sat, 17 Nov 2012, Debian Bug Tracking System wrote: > > My bug report was not about thoughtlessly setting 'Multi-Arch: same' > but rather more about making libtiff4-dev multiarch compatible.
Sorry, I didn't mean to imply that you were suggesting doing anything thoughtlessly, just that the original phrase "as long as there are no architecture-dependent headers" did not apply. > Or do you mean that your plan is to never make libtiff4-dev multiarch > compatible? My plan is not to do it if upstream is not going to do it. Upstream development on libtiff is very light since no one is working on it full time. Pretty much the only changes that are made are changes for which patches are supplied. In order for tiff headers to be architecture independent, /usr/include/tiffconf.h would have to no longer be installed. Upstream already knows that this is a bad thing to have done, and there are comments in the header that say the file is maintained for backward compatibility and definitions from it should not be used by end user programs. However, there is no way to know whether these definitions are used, and they probably are, so removing it would potentially break source compatibility. Given that this issue was not resolved during the recent release of tiff 4, which was disruptive because of its non-compatible changes (hence there still being two versions of tiff in wheezy), and given that tiff.h includes tiffconf.h and uses definitions from it, I don't believe this is likely to be fixed. While it would not be that hard to make the tiff package itself work without this file, there is a lot of code out there that could break. So, the bottom line is that I have no intention of addressing this issue, or as you put it, my plan is to never make libtiff4-dev multiarch compatible. It's not about laziness or being contrary; it's just that it's more than I have the time or inclination to tackle, particularly since doing this would be a deviation from upstream. That said, if someone wishes to provide a simple solution that doesn't involve creating a situation where debian's tiff is not source-compatible with straight upstream or tiff on other distributions, I would consider it. I just don't see any such solution existing given that there's no way to really know who depends on things defined in tiffconf.h that they get indirectly by including tiff.h, which must be included by all code that uses the tiff library. For some of my open source work, I went to effort from the beginning to avoid this pitfall. Sadly, xerces-c, which I also maintain, also suffers from the same problem as tiff: files generated by autoconf are installed, which prevents using Multi-Arch: same in the dev package. -- Jay Berkenbilt <q...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
