The Wanderer <[email protected]> writes: > Just as a note, one difference here is that there is support in the > archive and package-distribution mechanisms for having multiple versions > of a package for different architectures or (I think?) kernels, so that > you can build a version with some optional features for one architecture > / kernel but a version without those optional features on another - but > there is no such support for having multiple versions of a package for > different init systems.
> You can only have one architecture, only one kernel, and only one init > system active at any given time. The archive and its infrastructure > recognizes this for architectures and (I think) kernels, and supports > special handling for them to avoid or work around problems which would > (or easily could) otherwise be present. The archive and its > infrastructure do not presently recognize this or provide such support > for init systems; as such, no such workarounds are available. *looks at his packages that support systemd, upstart, and sysvinit* I think you're confused about where the hard parts of this process are. It's often easier to support multiple init systems in a package than supporting multiple architectures or multiple kernels. It's certainly nothing that tremendously difficult to do. The hard part isn't the support; it's the testing, but we have that problem already with multiple architectures. I build and test my packages on amd64 and then upload them and hope they work on, say, s390, but never look at an s390 system unless something breaks. There may be init scripts in my packages that I never use, and therefore won't notice if they break, but the same thing is already true of, say, the menu entries or the doc-base files. Other people who do use those things notice when they break and file bugs, or incorporate good tests into Lintian that will tell me what to do, and I do those things as part of maintaining my package. This is routine stuff in Debian, or at least it was before people started screaming and yelling at each other. I expect I'm not the only person who finds the screaming and yelling decidedly unmotivating, and who has cut back on Debian work as a partial reaction, but that's hopefully a temporary aberration in this way of working together. There are a few maintainers who don't merge such things, and that tends to provoke a lot of frustration and irritation, and usually (although not always) it gets worked around or undone in some way. Most people *want* to merge changes that help other people do things they want to do with their Debian systems, and it's rarely much of a contentious issue in practice. It usually only comes up when the maintainer and the patch submitter disagree about how hard the support will be to maintain in the long term. The packages that are causing all the controversy at the moment aren't created by some sort of archive limitations, or even by a breakdown of this process. The problem, rather, is that only one init system (or at least one init system's infrastructure; I'm counting logind as part of systemd here) supports some decidedly non-trivial features that those packages use, and no one has provided a supported implementation of those features for other init systems. In other words, they're very much akin to ZFS on FreeBSD. But we already have a reasonable workaround in the form of getting the systemd component to work under sysvinit. > It seems possible that some of the problems potentially / arguably > introduced by having features provided by only a subset of available > init systems could be avoided or resolved by having multiple package > versions for different init systems, There's no reason to do that if someone is willing to port it. You can combine it all into one package trivially. That's not the hard part; the hard part is replacing the functionality that the package relies on but which is only provided by one init system. That's why people are putting all that hard work into systemd-shim, which lets one use the systemd logind component without running systemd itself. Once that work is done, then packages that rely on logind don't need to do anything particularly special. It's possible there will be more things like that going forward: upstream packages that assume things like socket activation, for example. And it's quite possible to keep them working under other init systems using the same sort of tactics: add socket activation to start-stop-daemon, or find a way to use systemd under another init system to start the unit. The result probably won't be as efficient as systemd is, but that's typical for porting, at least at first. Or people could decide that they don't care enough to do the work, and init systems that don't support socket activation could die a natural free software death: they still exist, but not enough people use them to maintain critical math. That's not necessarily a bad thing. I've been working in free software for some twenty years now, and I can name a long list of things that I used all the time when I first started that died long ago. Most of them aren't mourned, because the software we're using now is, well, better. The software world changes fast. One learns how to let go of stuff, even stuff that one has put a ton of personal time and energy into. You have to, or you'd drive yourself nuts. (And then, many years later, you resurrect, say, C News as a hobby project in your retirement and happily putter away at it, no longer caring what the rest of the world thinks of your project.) Anyway, either outcome is possible in the long run, but given how many people seem quite enthusiastic about sysvinit support, there are obviously resources available for right now to keep it working. There are certainly way more people expressing strong opinions about keeping sysvinit working than there are people who express an opinion about, say, doc-base, and yet doc-base works pretty well across the archive. It's not much harder to maintain init scripts for typical packages. (Packages that need newer and more complex features are another, more complex matter.) -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
