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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75880 in the body.
You can then email your comments to 75880 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#75880; Package libtool. (Sun, 26 Jan 2025 22:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Karl Berry <karl <at> freefriends.org>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Sun, 26 Jan 2025 22:36:02 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: bug-libtool <at> gnu.org
Cc: luigi.scarso <at> gmail.com
Subject: relax five-digit maximum on revisions?
Date: Sun, 26 Jan 2025 15:35:07 -0700
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?
Can it be increased, perhaps allowing any number?

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?

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.




Information forwarded to bug-libtool <at> gnu.org:
bug#75880; Package libtool. (Mon, 27 Jan 2025 18:41:02 GMT) Full text and rfc822 format available.

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)]

Information forwarded to bug-libtool <at> gnu.org:
bug#75880; Package libtool. (Mon, 27 Jan 2025 19:05:01 GMT) Full text and rfc822 format available.

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

From: luigi scarso <luigi.scarso <at> gmail.com>
To: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
Cc: Karl Berry <karl <at> freefriends.org>, 75880 <at> debbugs.gnu.org
Subject: Re: bug#75880: relax five-digit maximum on revisions?
Date: Mon, 27 Jan 2025 20:04:24 +0100
[Message part 1 (text/plain, inline)]
On Mon, 27 Jan 2025 at 19:40, Ileana Dumitrescu <
ileanadumitrescu95 <at> gmail.com> wrote:

>
> 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.
>
>
Hi all,

Unix epoch  expressed in nanosecond is 19 digits:
$ k=$(date --date='now' +%s%N); printf $k|wc -c
19

--
luigi
[Message part 2 (text/html, inline)]

Information forwarded to bug-libtool <at> gnu.org:
bug#75880; Package libtool. (Mon, 27 Jan 2025 19:20:02 GMT) Full text and rfc822 format available.

Message #14 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 <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 21:18:44 +0200
[Message part 1 (text/plain, inline)]
On 27/01/2025 21:04, luigi scarso wrote:
> Unix epoch  expressed in nanosecond is 19 digits:
> $ k=$(date --date='now' +%s%N); printf $k|wc -c
> 19

Here is an updated patch for 19 digits.

-- 
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)]

Information forwarded to bug-libtool <at> gnu.org:
bug#75880; Package libtool. (Mon, 27 Jan 2025 21:14:02 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: ileanadumitrescu95 <at> gmail.com
Cc: luigi.scarso <at> gmail.com, 75880 <at> debbugs.gnu.org
Subject: Re: bug#75880: relax five-digit maximum on revisions?
Date: Mon, 27 Jan 2025 14:13:05 -0700
Thank you, Ileana!




Reply sent to Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
You have taken responsibility. (Tue, 28 Jan 2025 14:58:02 GMT) Full text and rfc822 format available.

Notification sent to Karl Berry <karl <at> freefriends.org>:
bug acknowledged by developer. (Tue, 28 Jan 2025 14:58:02 GMT) Full text and rfc822 format available.

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

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 75880-done <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: Tue, 28 Jan 2025 16:57:05 +0200
[Message part 1 (text/plain, inline)]
The patch has been updated and pushed to the development branch [1].

Thank you for the bug report and help improving libtool!

[1] 
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=7b49ee14f9f350e60d890fc109143aa721bf76a9

-- 
Ileana Dumitrescu

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

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 26 Feb 2025 12:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 119 days ago.

Previous Next


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