Re: [Buildroot] [PATCH 3/4] package/coreutils: rename package

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Sebastian,

On Tue, 14 Mar 2023 13:15:05 +0100
Sebastian Weyer <sebastian.weyer@smile.fr> wrote:

> In preparation for the addition of a virtual package providing the
> coreutils functionality, the package package/coreutils has been renamed
> to package/coreutils.
> 
> Signed-off-by: Sebastian Weyer <sebastian.weyer@smile.fr>

As it is proposed, this patch will break existing configurations that
have BR2_PACKAGE_COREUTILS=y enabled, as the option is being renamed.

A solution to that would be to substitute package/coreutils by a
virtual package *and* rename package/coreutils into
package/gnu-coreutils in the same patch.

However, I'd like to challenge the need of turning package/coreutils
into a virtual package in the first place. Virtual packages are very
useful for libraries that have multiple implementations, but also a
large number of users: OpenGL libraries, zlib, openssl, jpeg, etc.

Coreutils has almost no reverse dependencies in Buildroot:

package/e2fsprogs/Config.in:    depends on BR2_PACKAGE_COREUTILS  # runtime
package/e2fsprogs/Config.in:    depends on !BR2_PACKAGE_BASH || !BR2_PACKAGE_COREUTILS \
package/glslsandbox-player/Config.in:   select BR2_PACKAGE_COREUTILS # runtime (timeout)
package/opkg-utils/Config.in:   select BR2_PACKAGE_COREUTILS if !BR2_PACKAGE_BUSYBOX # runt

So I really don't think a virtual package is needed. We can handle the
two coreutils implementation manually in the very few places where it
is needed, and perhaps where it does matter for people.

Virtual packages are not "free" in terms of complexity and code churn.
In addition, I am almost sure that uutils-coreutils is not a 100%
drop-in replacement for coreutils. Most likely there are a few tools
that are missing, or a few options that are not supported, or differ in
behavior. And virtual packages for which the different implementations
are not strictly compatible generally cause quite a lot of pain (see
the mess around libopenssl vs. libressl for example).

What do you think?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot