Re: The plans for Alpine Linux

From: Laurent Bercot <>
Date: Sun, 28 Feb 2016 02:12:19 +0100

On 03/02/2016 18:30, Steve Litt wrote:
> The situation you describe, with the maintainer of a distro's
> maintainer for a specific daemon packaging every "policy" for every
> init system and service manager, is certainly something we're working
> toward.

  This is certainly a possible, even a desirable, setup, but it is not
necessary. One of the advantages of small package granularity is that
you have more flexibility in maintainership - you don't have to assign
the same maintainer to all the packages in a set. And that overcomes
most of the obstacles:

> * Daemon maintainer might not have the necessary time.

  Not a factor for the initial split: there isn't more total code.
Could become a factor when you add service managers, but the amount of
maintenance needed for 2 or 3 service managers should remain negligible
before the amount of maintenance needed for the daemon itself.

> * Daemon maintainer might not have the necessary knowledge of the init
> system or service manager.

  Then acquire it. You're a maintainer for a distribution? You better
know how your distribution works. How all supported ways of starting
your daemon work. That's your job as a maintainer.

  If it's really not possible, assign the maintainership of the package
with the new service manager policy to someone else, who knows the new
service manager.

> * Daemon maintainer might be one of these guys who figures that the
> only way to start up a system is sysvinit or systemd, and that any
> accommodation, by him, for any other daemon startup, would be giving
> aid and comfort to the enemy.

  If you're disagreeing with the political choices of a distribution, why
are you sticking with that distribution?

  See above: don't make people maintain things they don't want to maintain.
Find someone else who will. Small granularity to the rescue: I certainly
do not want to maintain mysqld, but I could probably be talked into
maintaining mysqld-init-s6rc if there was absolutely nobody else for the

> * Daemon maintainer might be one of these guys who tries to (example)
> Debianize the run script to the point where the beauty and simplicity
> and unique qualities of the service manager are discarded.

  That is a common risk with every package, and is orthogonal to the amount
of supported service managers, or their nature.

  I am not saying the obstacles are not real, or hard to overcome. I realize
they most certainly are. I am saying that the issues you are raising are
all of a human nature, not a technical one, and at this point that is not
what I want to focus on. When designing a solution, I am passionate about
being dispassionate; if the path to technical excellence is riddled with
hardships the only possible answer to is "get better maintainers", then
so be it. There will always be time to compromise later.

Received on Sun Feb 28 2016 - 01:12:19 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC