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 job.
* 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. -- Laurent