GNU bug report logs - #75880
relax five-digit maximum on revisions?

Previous Next

Package: libtool;

Reported by: Karl Berry <karl <at> freefriends.org>

Date: Sun, 26 Jan 2025 22:36:01 UTC

Severity: normal

Done: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 75880 <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 75880 <at> debbugs.gnu.org
Cc: luigi.scarso <at> gmail.com, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#75880: relax five-digit maximum on revisions?
Date: Mon, 27 Jan 2025 20:40:28 +0200
[Message part 1 (text/plain, inline)]
On 27/01/2025 00:35, Karl Berry wrote:
> Hi Ileana and all - in ltmain.in, there is:
> 
>      case $revision in
>      0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
>      *)
>        func_error "REVISION '$revision' must be a nonnegative integer"
>        func_fatal_error "'$vinfo' is not valid version information"
>        ;;
>      esac
> 
> Which allows for at most five digits of $revision.
> Is there a technical reason for that, or is it arbitrary?

It seems arbitrary to me.

> Can it be increased, perhaps allowing any number?

I am happy to increase the number for revisions, but I think accepting
any number may cause unforeseen issues in the future.

> My friend Luigi (cc-d) incorporates the luajit library into luatex with
> libtool. Luajit is now a rolling release. Therefore using epoch-seconds
> or similar seems reasonable, since there is no specific revision number
> other than that. For example, 1736781742 (corresponding to a couple
> weeks ago).
> 
> Wdyt?

I like the idea of basing it off of timestamps. From a quick search, the
longest timestamp I have seen was 18 digits. I would be fine with
changing it to something shorter or longer if there was a better use
case for it.

I have attached a draft patch for bumping the maximum for revision
numbers from 5 to 18. It also includes some more versions to test in
versioning.at.

> Thanks,
> Karl
> 
> P.S. I speculate that there's a technical maximum of 32 or 64 bits, so
> "any" number (as in \d+) would technically be wrong, but presumably such
> a huge number will fail at some point. IMHO the user doesn't deserve a
> nice error message if they exceed a maximum like that.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[relax-five-digit-maximum-on-revisions.diff (text/x-patch, attachment)]
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 154 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.