by senzilla on 8/3/22, 8:11 PM with 82 comments
by g051051 on 8/3/22, 9:36 PM
> More generally, and this is more a matter of opinion and totally debatable, I would like functionality to be progressively stripped from busybox-initscripts, which is a package that gathers a bunch of miscellaneous policy scripts that are only related by the fact that their mechanism is provided by busybox. I don't think this package makes sense from a semantics point of view; it is more logical to provide the policy scripts classified by service, no matter whether or not the implementation of the service is done by busybox. To me, ideally, busybox-initscripts would be empty, and we'd have virtual packages for every service that is currently defined in it, so support for alternative implementations can be added over time. This would also ease the path to getting out of busybox, or at least providing alternative coreutils/low-level utilities implementations, is there is ever a will from Alpine to do so.
So it sounds like they just want to change how the scripts are packaged. The only mention of getting away from busybox is at the end, which is qualified with "[if] there is ever a will from Alpine to do so".
by rahen on 8/3/22, 9:17 PM
by notacoward on 8/3/22, 8:34 PM
by yjftsjthsd-h on 8/3/22, 8:53 PM
Neat. I wonder if the general decoupling will make it eventually easy to drop in ex. toybox or one of the rust/golang coreutils implementations. Or, for that matter, to drop in GNU coreutils, since the current way to add those to Alpine strikes me as a little inelegant in comparison.
by LAC-Tech on 8/3/22, 10:12 PM
by octoberfranklin on 8/3/22, 11:36 PM
At most, this MR is reducing dependencies on busybox's init scripts.
A far more accurate title would be the title of the MR itself: "main/mdevd: make it a fully supported alternative to mdev". The MR is mainly about mdev.
by freemint on 8/3/22, 10:22 PM
by gtirloni on 8/3/22, 10:31 PM