[g051051]

That's not what I read in the link:

> 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".

[wpietri]

I like this part:

> 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.

That's a lesson I see learned over and over. Something like, "Group by meaning, not mechanism."

[WatchDog]

It's one of the many system factoring challenges. It's difficult to define a hard and fast rule as to which is better. Often some combination of the two is ideal, particularly as the system grows.

[andy_ppp]

Is this so that you don’t end up creating the wrong abstraction when inevitably over time the meaning changes and you end up special casing the implementation?

[tremon]

From Ariadne's update:

> The TSC [..] has concluded that there is a general need to begin decoupling hardcoded preferences for BusyBox from the distribution.

That's a bit stronger than just "we want to reorganize our script packaging". It still isn't explicitly "reducing dependencies on Busybox", but removing hardcoded dependencies is a prerequiste for the former.

[dundarious]

Debatable. I view it as a restatement of the goal to package scripts by service, instead of having a grab bag package for scripts, and one tied to a specific impl at that.

> 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.

[rkangel]

The underlying goal (in the long follow up message) seems to be the desire to move from mdev (in busybox) to mdevd (not in busybox) so the title is to some degree justified. Although the situation is a complicated and subtle one, as per usual with Linux distributions.