[Exherbo-dev] GNU coreutils alternatives

Kylie McClain somasissounds at gmail.com
Tue Sep 29 22:04:24 UTC 2015

On Wed, Sep 23, 2015 at 3:47 AM, Bryan Østergaard
<bryan.ostergaard at gmail.com> wrote:
> I'm a bit late to the party but here's my thoughts on the situation.
> First of all, I want good solid reasons why we should do this and everything
> I've seen so far have been fairly handwavy in my opinion. This is a rather
> big change with lots of potential for breakage and so we should have very
> solid reasons for doing it.

As Bo brought up in #exherbo-dev a while back, those same arguments could have
been given to things such as multiarch, calling them "handwavy" and all.
Though I realize this is a good bit different from the effects and possible use
cases that multiarch could have fulfilled, I don't think that makes the point
any less valid.

> Second, how many are going to benefit even a little bit from this? I know of
> 3 people or so that I've seen raising their hands and saying they're
> interested. But I'm not convinced anybody actually *needs* this.

It could be argued that no one really *needs* other alternatives as well.
I think, in the same way that people being interested in using alternatives to
the norms such as libav, libressl, gcc, a specific cron implementation, init
system, etc., we should allow people interested to pursue these things
given that
they are technically sound and, **don't hurt those uninterested**, which brings
me to the last points...

> And third, we've already seen tons of breakage from this work. Breakage that
> affects all of us And also breakage that a rather large part of us have
> trouble solving on our own as it often gets fairly toolchain specific and
> few have much experience in that area.
> Finally, am I the only one who's noticed several of the breaking changes
> borking Jenkins in rather unfortunate ways? This goes way beyond just the
> toolchain and it's not possible to just ignore toolchain related updates
> until the dust have all settled a few months from now. I'm not the biggest
> fan of Jenkins in Exherbo but most people rely heavely on it and they
> absolutely shouldn't be affected by toolchain changes like this.

The issues with the toolchain aren't really related to this change (unless I'm
getting what you're mixed up...). Those have been fixed now though and there
should not be any further issues with toolchain alternatives and other really
close-to-the-toolchain things.

The issues seen with the first try at the coreutils alternatives stuff has been
fixed, and Jenkins actually completed the build just perfectly a few
minutes ago.
I'm currently waiting for some others to test the change in Gerrit so that this
can be merged without any further issues or other painful things happening. So,
with Jenkins working just fine with it, I'm a bit more confident that this
functionality won't break anyone's systems.

Jenkins has also been fixed as well, thanks to our hero, zlin.

> So while I think this work could, in some small way, be interesting I have
> seen nothing at all that convinces me we should go forward with this.
> And to clarify something I brought up on irc when discussing alternative
> coreutils - my biggest concern there isn't actually bugs or small
> incompatibilities but rather that everybody is going to be affected by this
> again and again going forward. There's absolutely no way every time some
> random person runs into some issue they will go directly to Kylie.
> Realisticly speaking we're all going to be expected to fix these issues. For
> coreutils alternatives I might be willing as going so far as to accept them
> but have a rule saying it's in no way supported by Exherbo.

I did write some amendments to Exheres for Smarties relating to alternative
utilities... https://galileo.mailstation.de/gerrit/#/c/3711/

I still think it's safe to depend on users of these alternatives to be able to
fix any issues with packages that might be caused by these alternatives.

> /Bryan
> On Fri, Sep 18, 2015 at 4:44 PM, Bernd Steinhauser
> <exherbo at bernd-steinhauser.de> wrote:
>> On 18/09/15 09:23, Vasiliy Tolstov wrote:
>>> 2015-09-17 23:35 GMT+03:00 Bernd Steinhauser
>>> <exherbo at bernd-steinhauser.de
>>> <mailto:exherbo at bernd-steinhauser.de>>:
>>>     I actually had the same question.
>>>     On 17/09/15 21:39, Kylie McClain wrote:
>>>         On 09/17/2015 03:18 PM, Ciaran McCreesh wrote:
>>>             What is the compelling reason that makes it worth spending
>>> any effort
>>>             on this?
>>>         I have a few, actually.
>>>         1. It allows for more choice with respect to core parts of the
>>> system. I
>>>         wonder how quickly someone's going to crucify me for saying
>>> "choice" is
>>>         a reason. I believe it is reasonable to provide this option, it's
>>> not
>>>         that much different from how we provide the choice of libav over
>>> ffmpeg,
>>>         or libressl over openssl.
>>>     Well, this is not Gentoo. We don't like to introduce options just so
>>> there
>>>     is an option.
>>> Yes, this is not gentoo, but if we don't provide alternatives and options
>>> -
>>> Exherbo have not big difference compared to Archlinux.
>> There is a plenty of space between »no alternatives« and »a lot of
>> alternatives for stuff that doesn't matter«.
>> I'm not saying that we shouldn't provide alternatives. I'm saying that we
>> shouldn't provide alternatives for things that don't matter, just because we
>> can do so.
>>>     Does anybody really care about space on an Exherbo system (serious
>>> question)?
>>>     (We are talking about a few MBs here at most.)
>>> I'm care. I'm use exherbo on production to host user vps, and i need to
>>> minimize
>>> base system , becasue all system goes to memory (diskless host server).
>>> SO i need to remove all unneded stuff. And i don't need to full featured
>>> compiler and other tools in such case. I'm prebuild all stuff on build
>>> host and
>>> use it.
>>> So please don't think that nobody cares.
>> I don't. That's why I was asking. If people say that alternatives for tool
>> X matter, then we can certainly think about introducing them. No question
>> about that.
>> But with such a setup you're breaking the system anyway I guess. So the
>> question is if alternatives save so much time here?
>> _______________________________________________
>> Exherbo-dev mailing list
>> Exherbo-dev at lists.exherbo.org
>> http://lists.exherbo.org/mailman/listinfo/exherbo-dev
> _______________________________________________
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
> http://lists.exherbo.org/mailman/listinfo/exherbo-dev

More information about the Exherbo-dev mailing list