Bug#727708: systemd vs. binfmt-support
On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
> > As I explain in the bug [1], I think that the facilities provided by
> > binfmt-support are objectively superior; and even if they were broadly
> > equivalent, I'd still question the utility of converting packages from
> > an interface that's been well-established in Debian for over ten years.
> >
> > What is the systemd maintainers' position on this bug? I bring it up
> > here mainly because it's an interesting example of integration. Tollef
> > said during the committee's last meeting on IRC that he hadn't thought
> > much about binfmt before, so perhaps this is just a loose end.
>
> binfmt-support is, AFAIK, only used in Debian and derivatives and in
> general, I think having tools that are used across the ecosystem is more
> valuable than having tools that are only used for parts of the
> ecosystem.
Arch uses binfmt-support as well, I believe (and now I search for it I
see that it also ships systemd configuration for it, which will be
useful). I admit that I haven't put much effort into evangelising it,
but there's nothing especially Debian-specific about binfmt-support and
it ought to be trivial to make it work elsewhere.
> In this particular case, as you write, I hadn't really given it any
> consideration before, but what I think would make sense is to extend
> systemd to support the same interface as binfmt-support and then people
> who don't use systemd can use binfmt-support and those who use systemd
> (on Debian or elsewhere) can use systemd-binfmt. I'm guessing the
> file format of binfmt-support is stable and unlikely to change
> substantially in the future.
I think the last non-trivial file format change was in 2010, but there
are other interfaces (e.g. "update-binfmts --find", plus of course the
various ones used by humans) which are in use.
> This is the longer-term view. Short term, if there's any harm in having
> both enabled, having binfmt-support disable systemd-binfmtd (by masking
> it) would be fine.
I don't think there's much harm in having both enabled as long as their
files are disjoint, but it would probably be unwise to have them both
try to process imports from /usr/share/binfmts/ into /var/lib/binfmts/.
Some thought would be involved in terms of how the two approaches to
site-specific configuration (creating files in /etc/ vs. running
"update-binfmts --install" etc.) would interact.
> Does this sound like a reasonable plan, or do you have a preference to
> move in another direction?
Thanks for your reply. I can certainly see why you would have this
preference, and I suppose we both have fairly predictable biases. I'm
afraid it leaves me rather cold, though.
The first reason is, I suppose, rather selfish: I've been working on
this on and off for fourteen years and it seems a bit rude for systemd
to turn up and declare that it's now the standard on the strength of an
underpowered implementation, without even mentioning it to me (I'll
accept that this is irrational since the systemd authors probably
weren't aware of the prior art, but it's certainly my gut reaction). I
suppose I'm concerned what the incentive is for people to innovate on
this sort of thing in the future (and binfmt-support absolutely was
innovative in terms of making the packaging of the underlying kernel
technology trivially accessible) if they can be steamrollered at any
time; in the long term I have more faith in the flexibility of many
small projects than one big one.
The second is that it seems like makework for the sake of aggrandising
systemd. systemd isn't bringing anything new to the table here; right
now it's just exposing the raw underlying kernel interface in the form
that's existed since 1997, and in a way that (AIUI) only works properly
at boot time rather than doing sensible things when packages are
installed or removed. Of course you can put all the pieces together,
but that was the point of binfmt-support. This is straight
wheel-reinvention and it seems like a total waste of everyone's time.
Given that binfmt-support is doing a better job, my preference would be
to put a small amount of work into making it more clearly an independent
upstream project, and simply get more distributions using it. Doing
Fedora, Gentoo, and openSUSE would cover most of the bases. Now that
I'm aware of the effort being wasted on reinvention, I can move that
sort of thing further up my list.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: