Re: file(1) now with seccomp support enabled [and 1 more messages]

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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 <ijackson@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.