On 30/01/2016 00:14, Alex Suykov wrote:
I don't like the idea of introducing dozens of tiny packages, one per daemons per service manager, which is probably the only way of doing this with common package managers.
It's not the only way, but it's the only scalable way, from a maintainability point of view. Proceeding otherwise makes it unfairly hard on the maintainer of either the daemon packages or the init-scripts package; dozens of tiny packages may not be aesthetically pleasing, but they spread the maintenance burden.
But in this particular case there is an alternative: one policy package per manager providing startup files for all supported daemons.
This is indeed valid for Buildroot, as you say, because it does not worsen its already weak scalability.
I did it with sninit because I have startup files there already, but the same can be done with buildroot-s6 just as well. This trick probably won't work with proper distributions, but Buildroot may still be useful as a sort of staging and testing environment.
I don't think it would be good as a testing environment, because having a monolithic "policy package" requires the package to be complete, as in include startup scripts for every service defined by Buildroot, before being integrated and made available as an alternative. In a traditional package management environment, every package providing a service can be split separately without breaking anything, and so the work effort can be incremental. However, once the startup scripts for a given policy exist and are well-tested, it should be easy to integrate them into a Buildroot "policy package". -- Laurent
