Re: [Buildroot] minimum system/coreutils requirements (was: support/download: add blake2b-256 hash support)

[yann.morin@orange.com]

Marcus, James, All,

On 2026-06-18 16:04 +0200, Marcus Hoffmann spake thusly:
> On 6/18/26 07:51, yann.morin@orange.com wrote:
> > On 2026-06-17 11:42 -0600, James Hilliard spake thusly:
[--SNIP--]
> > b2sum was only introduced with coreutils 8.26, but we support running on
> > systems that have an older version: we already check that ln supports
> > --relative (introduced in 8.16) and that realpath exists (introduced in
> > 8.15).
> 
> Coreutils 8.26 was released almost 10 years ago, 8.15 was released
> (slightly) over 14 years ago. I wonder at what point we can assume that
> having a version with the required functionality is a given. 10 years is not
> thaaat long ago in lts distro terms, I suppose, but even debian
> old-old-stable has b2sum already. I also wonder if buildroot actually fully
> works on a 10 or 15 year old system. Without known users or actual automatic
> tests being run it feels kind of weird to assume it does.
> 
> Anyway, thoughts about this? Anyone got actual experience on running
> buildroot on these old systems? (I'm more on the side of running into
> breakage on the newest stuff on archlinux)

Thing is, either we clain we can run on such systems, and so we extend
the existing checks for those, or we don't claim so and we can drop the
tests.

But since we have the tests for ln --relative and realpath, we either
need to raise the requirement for coreutils on the host, or we also need
to test for b2sum. We can't test for ln -relative and realpath on one
hand, but not for b2sum on the other.

[--SNIP--]
> It's not super great though because if someone where to add a blake2b hash
> for a non-python package which then someone would try to build on an old
> distro it would still break, I think?

Sure, but then it would be a bug in Buildroot; as I said, a package that
adds a blake2 hash would have to have a dependency on
BR2_COREUTILS_HOST_DEPENDENCY.

Unless of course we decide to raise the bar to require at least
coreutils 8.26 or later... But since this is not currently the case, I
think it is easier to also check for b2sum for now...

> I guess I'd mostly like to know if this complexity is actually worth it and
> if we would want to at least define a minimum supported coreutils version
> which we could bump at some point to get rid of these checks again.
> Opinions?

Some people did complain in 2019-or-such that they were still running
with system dating from before 8.15 (released 2012, 7 years before), so
had issues with ln --relative and/or realpath. That makes for 14-year
old systems today; even entreprise-grade distros that are that old and
still in maintenance are few: RHEL 6, released 2011, got EOLed in 2024,
while RHEL 7 was released 2014 and will get EOLed in 2028...

In any case I was just pointing to a discrepancy betweeni how we handle
various tools provided by coreutils... Whatever the eventual outcome, I
don't care much, as long as it is homogeneous.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot