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
Received on Sat Jan 30 2016 - 09:23:01 UTC