On Wed, Nov 13, 2019 at 02:59:51PM +0100, Matthias Klumpp wrote:
> Exactly this. I think I would definitely second a "focus on systemd"
> amendment which makes packages support systemd as a priority, but
> doesn't force out sysvinit or any other init system from the archive.
> I think there's a valid point in having them, and as long as they
> don't impair the default init system and people aren't forced to do
> work they can't test, it's fine to have them.
indeed.
> So, something like this maybe? (adapted from Alexander E. Patrakov's text):
> ```
> Choice 4: Focus on systemd as init system and features requiring it
>
> The Debian project recognizes that systemd service units are nowadays
> the preferred configuration for describing how to start a daemon/service.
> Packages should include service units. At the same time,
> the Debian project acknowledges that maintainers and upstream developers
> are often unable to provide high-quality (or any) support for alternative
> init systems in their packages on their own and can not or do not test
> that their
> packages work under such init systems. It is not realistic to expect
> the situation to improve, and Debian does not want to block
> experimentation with new Linux-based technologies developed under the
> systemd project umbrella or hinder their adoption by requiring all
> other init systems to support the same features as well (which may not
> even be desired by those projects).
> Therefore, Debian should focus on a polished experience with systemd
> as init system as first priority. Other init systems will remain
> available as long as there is enough interest by people to maintain
> them. Package maintainers are encouraged to accept patches to support
> non-systemd configurations, as long as the changes do not impair the
> user experience when systemd is available. Package maintainers may
> split out support for alternative init systems into separate binary
> packages. Maintainers of other init systems are encouraged to test
> support for their configurations if the package maintainer can not do
> it.
>
> Debian is still committed to working with derivatives that make
> different choices about init systems.
> ```
> This would mean that it's not a bug if no sysvinit script is provided
> by a package and only a systemd unit is available. Also, if a sysvinit
> script is faulty, such an issue would be a normal/important bug and
> wouldn't get a package removed or excluded from release. At the same
> time, maintainers of alternative init systems could add support for
> their systems, as long as they test it (CI/autopkgtest may help
> there).
> Any alternative init system would very much be second-class, but so
> are alternative kernels, or compilers, or libc implementations, or
> architectures (or desktop environments, some would argue), and that
> doesn't stop people from doing awesome work on them. And if we ever
> want to switch away from systemd to something else, we still could -
> but until then, the experience with it should be as good as we can
> possibly make it.
>
> This is not a finished proposal, but something I would be much more
> likely get behind compared to a "systemd and completely screw
> everybody who wants something else by policy" approach.
many thanks for writing this up. I'd second such an amendment. With two
small changes:
- s#This would mean that it's not a bug if no sysvinit script is \
provided#This would mean that it's not an important (or higher) \
bug if no sysvinit script is provided#
- s#normal/important bug#norma bug#
--
cheers,
Holger
-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Attachment:
signature.asc
Description: PGP signature