Re: Tentative summary of the amendments
On Wed, 2014-10-22 at 22:25 +0300, Aigars Mahinovs wrote:
> On 22 October 2014 20:14, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
> > Ian Jackson wrote:
> >> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> >> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
> >> > > I believe Ian's intended reading is that a package that depends on
> >> > > uselessd | systemd (but does not work with sysvinit) would be allowed
> >> > > by his proposal.
> >>
> >> Yes.
> >>
> >> In practice such packages are not going to be a big problem because
> >> writing init scripts for them would be straightforward, and then the
> >> dependency could be relaxed.
> >
> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd?
>
> That would not be a problem, because uselessd is only an init system
> and does not include all the extra services that systemd does, for
You're not replying to what was the point of that paragraph. I was not
arguing that the GR might fail to outlaw things its proposers dislike.
The essential part was what you cut away:
> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd? Does the GR still
> > require "someone"(tm) to package uselessd for Debian before
> > packaging
> > that other (fundamentally OK even by your standards) software is
> > allowed? To polish uselessd integration until it's actually a usable
> > init system in Debian? I assume you are not volunteering for this
> > work?
In another mail, Ian said that his interpretation is that the init
system would not only have to be packaged in Debian, but in testing and
not RC buggy.
So even GR proponents agree that software which works with either
systemd or uselessd would be fine. Yet they want to FORBID packaging
such software, unless someone packages and integrates uselessd for
Debian. That's a large amount of work which would be mostly unrelated to
the software running under those systems. And the proponents are not
volunteering to do such work.
> example - logind is not a part of uselessd. Therefore, even if
> uselessd is packaged tomorrow, there would still be just one init
> system in Debian implementing this feature. So the Ians proposal makes
> it a bug to depend on features that are only implemented in one init
This is technically inaccurate. Logind is used under other init systems
with cgmanager+systemd-shim (otherwise the claim that this GR would make
no difference for Jessie could not be true). Also, logind is not part of
the systemd init process either; it only requires the system to support
APIs that other init systems lack. So whether logind is shipped as a
"part of" uselessd doesn't necessarily matter much. I don't know whether
uselessd retains the APIs required by logind.
> I think that practical effect would be the same if we mandated
> "support running with at least one non-default init system at PID 1"
> or "support running with sysvinit at PID 1" or "support running with
> any init systems in the archive at PID 1" from the point of view of
> software being able to start with an alternative init system managing
> the installation (not from the point of view of having init scripts
> for all init systems).
That's kind of backwards - the practical effect of the GR is pretty much
to require that everything must implement sysv scripts, while there are
init features that should not be considered to be/remain specific to
systemd but sysvinit does not support. For example, any init system that
Debian might want to switch to in the future will support systemd-style
socket activation. Uselessd probably supports it. Of course, support for
socket activation could be implemented on top of sysvinit - but AFAIK
the GR proponents are not volunteering to implement that either.
Before Debian selected its next init system, there were three that could
reasonably work for a distro like it: sysvinit, Upstart and systemd.
Most of developers and all of tech-ctte agreed that sysvinit is outdated
and it was a choice between Upstart and systemd. Now Upstart is not a
real alternative any more, and no new system has risen to the status of
a credible contender yet. The GR talks about alternative init systems in
general, and tells people that they must support at least two, any two
they like. In practice it allows selecting any two from the set
{systemd, sysvinit}.
By making the hurdle as high as requiring that the alternative init
systems have actually been packaged and integrated in Debian, the
practical effect of the GR is pretty much "must support sysvinit", tying
Debian down to support an obsolete system (which even the GR proposer
agreed "has many longstanding bugs and deficiences", at least before he
knew that the only remaining alternative was systemd).
Reply to: