[Exherbo-dev] GNU coreutils alternatives

Kylie McClain somasissounds at gmail.com
Wed Sep 16 19:31:21 UTC 2015


Hi everyone, I have a lot to cover in this so I'd like to layout exactly
what I'm proposing.

1. Virtuals for coreutils, sed, and grep have been added and are in the
system set. Currently they don't do much. The idea is that the user will
be able to use providers to set their preferred userland;
[providers:gnu], [providers:busybox], etc. GNU coreutils provides a
library (libstdbuf.so) that is used internally, but it is not used by
any other programs, so it can be safely replaced without linkage issues,
and therefore is candidate for a virtual rather than per-package
providers options.

2. Changes for sys-apps/coreutils which add an alternatives module named
'coreutils' are in Gerrit right now. I already tried merging them a few
days ago and it... didn't go well. But, that change was reverted, and
there's a better and more stable method now, which is found at[1].
Anyone who is able to fix their coreutils without panicking, please test
and give feedback.

3. I propose that Exheres specification should be changed to allow for
coreutils implementations, sed, and grep implementations which are very
compatible with their GNU implementations. (toybox, busybox both fit
this very well from my testing)

4. Compatibility issues between a package expecting GNU coreutils should
either have a bug report filed with the upstream of the coreutils
implementation (if we it can be confirmed that's not expected behavior),
have a report filed with the upstream of the package if we have reason
to believe they don't specifically request GNU coreutils,
or add a dependency on sys-apps/coreutils to the package in question.

I want to make it perfectly clear that I have no intention of making us
start providing workarounds or start appealing to the lowest common
denominator for our Exheres. We should still code to GNU coreutils as
the standard, and we can depend on users of these choices to send in
patches for fixes; the goal here is to provide the ability for a more
minimalistic and more flexible core of the system than what we have.
It is not to degrade the quality of our packages or code in an attempt
to pursue stupid amounts of choice.

Questions? Feedback?

[1]: https://galileo.mailstation.de/gerrit/3663
-- 
Kylie McClain, Exherbo Linux developer and Musician
https://somasis.com - https://github.com/Somasis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20150916/d8a0c9c6/attachment.asc>


More information about the Exherbo-dev mailing list