Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
The Wanderer <wanderer@fastmail.fm> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: