Re: New program: rand(1)

[Erik Auerswald]

Hey Tim,

On Sun, Aug 21, 2022 at 07:38:39PM +0000, Tim Rice wrote:
> [...]
> >I think this would be fine if done as an optional dependency to
> >add more functionality.  Without GSL, rand(1) could IMHO still
> >function, but be limited to functionality not implemented with
> >GSL.
> 
> Hmm, yeah, good thought. The --version flag could indicate whether
> the extra functionality was compiled in, like in Vim?

That seems like a good idea.  GNU Awk uses this, too:

    $ gawk --version | head -n1
    GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.2.0)

> [...]
> >With rand(1) being a new addition not yet included in a formal
> >GNU Datamash release it would seem OK to change course and require
> >GSL for rand(1), but neither datamash(1) nor decorate(1).  It
> >could be determined during ./configure if rand(1) can be built
> >or not, and only rand(1) excluded without GSL.
> 
> That sounds fair, with one caveat. Part of the motivation for
> including rand(1) in GNU Datamash is it allows benchmarking to assess
> new features or optimizations, as well as testing some functionality
> like the jarque operation.
> 
> I am okay with not enabling such tests by default, so long as we spell
> out in HACKING.md that benchmarking is recommended for certain types
> of development. So, anyone who is thinking about contributing to GNU
> Datamash would be encouraged to also build rand(1). Especially if
> their proposed changes may affect GNU Datamash's performance.
> 
> This all started when I was thinking about adding more compiler hints
> to increase vectorization. I realized I had no good way to assess what
> difference it makes :)

I think that is fine.  Tests using rand(1) could be skipped if it is
not available.

> >The addition of rand(1) has already placed some burden on packagers,
> >since at least Ubuntu already has a "rand" package[1] containing
> >a rand(1) binary[2].  The Debian packaging system has provisions
> >to handle this and they probably need to be used for the next
> >GNU Datamash release.
> >
> >[1] https://packages.ubuntu.com/kinetic/rand
> >[2] https://launchpad.net/rand
> 
> Ah, my distro doesn't have that package. Thanks for the heads up.
> 
> Do you know if there is a process for giving Ubuntu packagers a heads
> up about the potential conflict? I'm not sure if I can count on them
> to read the NEWS file in every GNU package :)

I don't know.  I suppose we could look for contact information regarding
Ubuntu's "rand" package maintainer(s) and tell them about this.
We should send a copy of such a  message to the Ubuntu "datamash"
package maintainers, too.

In a way I would expect a package maintainer who finds out that a new
program has been added to a package to check if this creates a conflict
with some other package, but since we have seen this already we might
tell them in advance.

> Thinking about Ubuntu packaging is on my radar anyway. We probably want
> GNU Datamash v1.8 to go into 22.10, and the next version after that
> should go in 23.04. It is unclear to me how automatic that process is.

Well, we could file a "new upstream version available" bug against the
Debian datamash package, and possibly the Ubuntu datamash package, too.

Both Debian and Ubuntu seem to be at version 1.7:

  * https://packages.debian.org/sid/datamash
  * https://packages.ubuntu.com/kinetic/datamash

It seems to me as if the Ubuntu package is basically taken from Debian
without a dedicated maintainer (the "Ubuntu MOTU developers" are listed
as maintainer).

Fedora seems to still be at 1.6, possibly because of the build and test
errors they reported regarding 1.7:

  * https://lists.gnu.org/archive/html/bug-datamash/2022-01/msg00003.html
  * https://lists.gnu.org/archive/html/bug-datamash/2022-02/msg00000.html
  * https://lists.gnu.org/archive/html/bug-datamash/2022-03/msg00000.html

GNU Datamash 1.8 should contain fixes for those issues.

> I was going to wait until 22.10 is released and then check whether
> its GNU Datamash version has bumped appropriately. I figure we have
> 18 months to get this right before the next Ubuntu LTS release in 2024.

I do not think we need to wait for some distribution release before
hinting at the availability of a new released GNU Datamash version.

> [...]

Br,
Erik