Christoph Biedl writes ("file(1) now with seccomp support enabled"): > tl;dr: The file program in unstable is now built with seccomp support > enabled, expect breakage in some rather uncommon use cases.
Thanks for this work and for the heads-up. PS: Did you really mean to send your first mail like thiks From: Christoph Biedl <debian-devel@lists.debian.org> ? It seems rather odd :-). Christoph Biedl writes ("seccomp woes (was: file(1) now with seccomp support enabled)"): > Solutions I've seen (use codesearch to find examples): > > * People don't care > * People add a hard-coded list of archs into the dependency clause > like "libseccomp-dev [amd64 ...]" > > The first I consider plain ignorant. Quite. > * 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. Others have pointed out that for good reasons the buildds insist on the first alternative. But maybe we could create a meta package like this Package: libseccomp-dev-maybe Depends: libseccomp-dev [!unsupported arch list] Architecture: all That would be available and installable on all architectures and you could depend on that. It would centralise the unsupported arch list and could be generated easily by src:libseccomp-dev. Can anyone see a problem with this idea ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.