"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Omar Polo <op@omarpolo.com>
Subject:
Re: [portable] remove util/got-portable-ver.sh
To:
Thomas Adam <thomas@xteddy.org>
Cc:
gameoftrees@openbsd.org
Date:
Sun, 26 Feb 2023 22:22:35 +0100

Download raw body.

Thread
On 2023/02/26 19:18:32 +0000, Thomas Adam <thomas@xteddy.org> wrote:
> On Sun, Feb 26, 2023 at 11:54:19AM +0100, Omar Polo wrote:
> > While trying the update of the package for void linux to 0.84 some
> > issues arised (then fixed in 0.84.1) but the biggest one (from a
> > porter POV) is that it's currently impossible to tweak configure.ac
> > and re-gen it with autoreconf from a distribution tarball.
> 
> In my experience, it's generally not the done thing to expect to regenerate
> these files.  The whole point of the release tarball is that it already has
> all the files required for compilation, without the need to regenerate
> anything.

This is the only point in the mail where I disagree.  It happens very
often instead.  There may be lots of different reasons (some
dependencies was updated and things are not in their place anymore, a
compiler change, ...) where a porter needs to fix something in how the
configure script works and can't wait for a new release to pop up.
Sometimes you can get away with patching the generated `configure'
but... it's not something nice.

We have a lot of patch-*configure_ac files in the ports tree.

> However, it's not a difficult thing to fix.
> 
> > The main issue is that util/got-portable-ver.sh is not shipped in it.
> > However, I'm failing to see the benefit of it.  It just echoes back
> 
> It's one of the biggest features I rely on when I'm juggling multiple got
> installations, and I look at the version string all the time to understand
> where got was built, and from where.

This proposal was driven by the objective inability to regen from a
dist tarball, but the actual diff was driven by the fact than I
personally don't like having git (or any other VCS) involved in the
build.  But that's just me, and since for releases git is not invoked
at all, fine with me.

(my biggest complain about having git, or whatever, involved in the
build is that it may change the build if present, or even fail it if
not.  I had at least a port that failed on bulk builds because it used
git(1) which was not installed in the build machine and stopped the
build.  Since then, every time I see a git call in the build tool I
patch it out.)

> > (there's also the point that some ancient autoconf -- still packaged,
> > for e.g. on void linux -- don't understand m4_esyscmd_s and fail.)
> 
> I'm less sympathetic on this point, Omar.
> 
> I will add util/got-portable-ver.sh to EXTRA_DIST.  For those systems where
> autoconf is that old that it doesn't understand m4_esyscmd_s, I consider them
> broken.  This was added to autoconf-2.63 which was released a while ago.

Wholeheartedly agree!  I mentioned as a "curiosity", but it wasn't a
reason for the change, and I'm inclined to consider it an issue of
that distribution too.

Thanks for promptly fixing this and taking care also of the other
diffs! :)