Bug#727708: Init system resolution open questions
On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> > If I was a systemd maintainer I would consider it a reasonable option to
> > rather upload a new version of systemd that adds such a dependency to
> > udev instead of shipping an ancient systemd in the next release.
> >
> > Or would you want to ship systemd 204 in jessie if that would
> > hypothetically be the only option for providing logind for
> > non-systemd in the jessie timeframe?
>
> That's not the point. The point is that it's not reasonable to break
> other people's packages in a significant and work-intensive manner two
> weeks before release, which is your scenario. There is no way that's
> ok. On the other hand, trying to formalise exactly how much you can
> inconvenience somebody how far in advance of the release is a futile
> exercise. Is requiring one other package to make a tiny change two
> years in advance of the freeze ok? If so, how about one year? One
> month? 20 days? etc. Don't regulate it explicitly but tell people that
> they have to behave reasonably towards their fellow developers.
>...
The problem is not a question of weeks or years.
It is about setting the goals that should be achieved before discussing
the way to reach them.
Possible goals that require Debian to support multiple init systems
include:
- allow everyone who dislikes systemd to have the full functionality
of Debian available with a different init system or
- provide all/some major desktop environments with non-Linux ports or
- allow non-Linux ports to be fully functional as server (but not
necessarily as desktop) or
- ...
Let me make an example where that affects you: [0]
When I asked regarding switching the init system of a running system,
Ian Jackson answered:
It seems obvious to me that if multiple ones are supported that there
has to be some way to get from using one to using a different one.
So if anything is not working regarding switching a running system from
systemd to sysvinit for jessie,[1] then that will be a (likely RC) bug
in your package [2] that you as systemd maintainers will have to fix.
Making you spend your efforts on supporting switching the init system
to and from systemd only makes sense when that results in actually
reaching a goal that is considered worth the effort.
Supporting multiple init systems alone is not sufficient for achieving
any of the possible goals I've listed above, and the effort is only
worth it when there is a clear understanding of the goal(s) and the
complete requirements for achieving these goal(s).
cu
Adrian
[0] assuming the decision is "multiple init systems, including systemd"
[1] it would clearly involve a reboot, but calling the right reboot(8)
can already be tricky
[2] assuming the problem is not on the sysvinit side
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: