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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org