Aurelien Jarno wrote: > Allowing multiple coreutils implementation, changes the features that > maintainer scripts can expect to be available and restrict them to POSIX > only. People already started filling bugs about that. This will also > likely causes many packages to FTBFS or provide different content. > > For instance coreutils-from-busybox (which seems to be installed by > default as part of the upgrade, see #1126264), does not provide the -m > or -s option of realpath. Their replacement by fully POSIX code is not > trivial and I am worried that we will end up with different open coded > version of it, with various kind of bugs, possibly serious ones.
Agreed. I don't think it makes sense to provide `coreutils-from-*` packages for implementations that aren't striving for full coreutils compatibility. Or, in other words, I think the standard for a `coreutils-from-*` package should be: - If it works with coreutils-from-gnu, and does not work with coreutils-from-X, is that a bug in X? If so, provide a coreutils-from-X package. If not, don't. coreutils-from-gnu axiomatically meets that standard, and coreutils-from-uutils meets that standard, but coreutils-from-busybox and coreutils-from-toybox do not. It's nice to be able to build a container using busybox instead of coreutils, and there are use cases for that. Perhaps it makes sense to have a permanently experimental package or other similar mechanism for "opt in to doing this, accept any breakage, don't file bugs". But this isn't something people should do on a normal Debian system and expect to be able to file bugs about.
