Christian Seiler wrote: > I have a question here: package A build-depends on libB. A has > Arch: any or Arch: linux-any in debian/control. libB OTOH only > has e.g. Arch: amd64 i386 mips in it's control file.
Concrete example: https://bugs.debian.org/811554 There I suggested blacklisting known-bad arches rather whitelisting the ones that are known to work. > Disadvantage: listed as BD-Uninstallable on multiple > architectures where libB isn't built I think that is not a problem, unless the package has built before in sid and is now out-of-date. > explicitly list the architectures of libB also in A > [...] > Disadvantage: requires source upload to build on new arch > once libB is ported With 20+ arches, I don't expect package libB's maintainer could keep up with new arches appearing that it could build and work on. If dependencies also kept such a list, I just don't think it would scale. A down-side to an overly liberal Architectures list is, building a package that doesn't work: but if you don't build it, who will ever test it (especially if many build-deps took the same attitude)? Having tests run during package build or CI tests could help here. Or, packages build accidentally, then a later version FTBFS. That's why I thought of auto-removals, but if porters more actively removed those I think it would be helpful. Regards, -- Steven Chamberlain ste...@pyro.eu.org
signature.asc
Description: Digital signature
