Hi, Quoting Geert Stappers (2019-07-20 07:50:11) > On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote: > > On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote: > > > > > * Centralize the list of supported archs in the seccomp packages. By > > > either creating an empty libseccomp-dev for the archs where seccomp > > > is not supported, or by creating a "libseccomp-dev-dummy" for these. > > > In the latter case package maintainers would have to do a one-time > > > change of the build dependency into "libseccomp-dev | > > > libseccomp-dev-dummy" and can focus on other issues then. > > > > AFAIK this won't work because sbuild on the buildds is configured to > > only use the first alternative from a list of build dependencies. Yes it will work. Please read Christoph's proposal again. There is an "or" in the second sentence. A solution that either produces an empty libseccomp-dev package or a libseccomp-dev-maybe package which either does or doesn't depend on libseccomp-dev, depending on the architecture will work perfectly fine with sbuild as it is configured on the buildds. > Reported as bug. > > Not checked if it already was reported before. > Not checked if it really fails when it can't find > the first alternative from list of build dependencies. > > Thing is that sbuild _might_ be blocking > a nice way to cope with libraries that are not available > on all architectures. No it does not block this. The sbuild configuration variable $resolve_alternatives or the command line option --resolve-alternatives allows one to enable or disable that sbuild only uses the first alternative. As Gregor also correctly wrote, the problem is not sbuild but how sbuild is configured on the buildds. You might want to re-assign the bug to the buildd admins if you really want to propose that the handling of alternatives is changed. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature