Re: sbuild: do not fail when there are alternatives
On 2019-07-20 07:58, Johannes Schauer wrote: > 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. This is indeed something configurable at the wanna-build level. > 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. This is done on purpose in order to provide stable features over time. If a package build-depends on foo | bar and foo is temporarily uninstallable (for example due to a transition or a version mismatch between arch:all and arch:any) bar will be used instead, possibly disabling some features in the package. In the file & libseccomp example, it means seccomp support might be silently disabled. Note that for backports, alternatives are considered, as the above is very unlikely to happen. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: sbuild: do not fail when there are alternatives
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 signature.asc Description: signature
sbuild: do not fail when there are alternatives
Package: sbuild Previous-Subject: Re: seccomp woes Original-To: debian-devel@lists.debian.org 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. 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. Context at https://lists.debian.org/debian-devel/2019/07/msg00405.html Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
