bug#48214: inetutils-1.9.4 build fails

[Bone Baboon via Bug reports for GNU Guix <bug-guix@gnu.org>]

> Bone Baboon via Bug reports for GNU Guix writes:
>> I have reported this to the inetutils bug mailing list and asked if the
>> inetutils test suite could be modified so that syslogd.sh does not fail
>> if IPv6 is disabled.
>
> I received this response on the inetutils mailing list:
>
>> Hi.  Thanks for the report.  Could you investigate if the
>> tests/runtime-ipv6.c program return appropriately?  It is supposed to
>> check wether the runtime system supports IPv6 or not, and should detect
>> this properly on your system (or there is a bug in the self-test code
>> elsewhere).
>> 
>> Looking at the code, I don't think a getaddrinfo-lookup is sufficient,
>> the code probably need to attempt to listen to a socket too, in order to
>> fully test wether IPv6 is disabled globally or not.
>
> I looked for tests/runtime-ipv6.c in the inetutils's build tree.  I
> could not find it.  I looked up the current version of inetutils which
> is 2.0.  Guix has 1.9.4 of inetutils packaged.
>
> Based on the response I received on the inetutils mailing list it sounds
> like updating the inetutils package to 2.0 may resolve this failing
> test.

On the inetutils mailing list it was suggested that I try inetutils 2.0
on the core-updates branch.  I can successfully build inetutils 2.0 from
the core-updates branch even with IPv6 disabled.

What is the purpose of the core-updates branch?

If inetutils follows semantic version numbering then that would suggest
a breaking change to the inetutils API moving from 1.9.4 to 2.0.  Can
the Guix master branch provide inetutils 2.0 instead of 1.9.4?

How can I use a package definition from core-updates with guix build or
in a system configuration if it is not available on Guix's master
branch?

What are the reasons I might not want to use a package from the
core-updates branch?