Hi Piotr, 2017-12-04 23:16 GMT+01:00 Piotr Ożarowski <pi...@debian.org>: >> So, Piotr, do you think that any of the options is preferable? >> >> If there's no reply I'd like to upload an NMU with a fix for this >> problem. >> >> I think that changing the package to "Architecture: any" and "M-A: same" >> is safer than dropping a dependency to recommends. It's not ideal, but >> in the end is just causes a small overhead, and changing dependencies >> can even break reverse-depends and introduce bugs difficult to detect. > > please point me to the policy if it's already known what's the right > approach
It's not documented in Policy yet. The best source of information is: https://wiki.debian.org/Multiarch Although probably Ubuntu is best/more accurate/more complete: https://wiki.ubuntu.com/MultiarchSpec Abut this package, since the package could be marked "foreign" (as in "package from foreign arch satisfies dependency") if it was only for its contents (because it's an arch:all, the same in all arches), but since it exposes arch-independent behaviour throught dependencies (i.e. needs to load arch-dependent modules for markupsafe), it cannot be marked in that way, which is the most beneficial and the original suggestion. It has to be marked as "give me the version for the same architecture that the package to be built that depends on this one". Despite having binaries in /usr/bin/ and libraries shipped in /usr/lib but not /<triplet>/ (see next url), since they are byte-for-byte the same across architectures, it should be covered by the same provisions as if the files were in /usr/include (but not inside subdir /<triplet>/), /usr/share, etc. -- at least that's how I interpret it. https://packages.debian.org/sid/all/python-mako/filelist Regards. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
