[PATCH] Show patchlevel in version string

[PATCH] Show patchlevel in version string

[Wesley Schwengle]

When building zsh with a custom patch level you cannot quickly see which
patchlevel you are on via `zsh --version'. When using zsh on Debian or
in my case, where I run the git version of zsh the patch level is hidden
in an environment variable ZSH_PATCHLEVEL. Git for example shows you the
git revision when issues `git --version' as seen here:

  $ git --version
  git version 2.33.0.113.g6c40894d24

This shows directly what version a user is running without having to
know about ZSH_PATCHLEVEL.

Because I'm not aware how downstream deals with a difference in version
strings I've decided to add it to the vendor/os type bit. Debian for
example uses `debian/5.8-6+b2' as a patch level. This would probably
break scripts which expect `zsh x.y.z' if the patch level replaced the
ZSH_VERSION string.

After this patch is applied, you get to see the following version string
after you configured zsh with `--enable-custom-patchlevel=$(git describe)':

  $ ./Src/zsh --version
  zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)

Signed-off-by: Wesley Schwengle <wesley@opperschaap.net>
---
 Src/init.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Src/init.c b/Src/init.c
index 878a53a37..a04d599c3 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -421,8 +421,14 @@ parseopts(char *nam, char ***argvp, char *new_opts, char **cmdp,
 		/* GNU-style long options */
 		++*argv;
 		if (!strcmp(*argv, "version")) {
+#ifdef CUSTOM_PATCHLEVEL
+		    printf("zsh %s (%s-%s-%s/%s)\n",
+			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE, CUSTOM_PATCHLEVEL);
+#else
 		    printf("zsh %s (%s-%s-%s)\n",
 			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE);
+#endif
+
 		    LAST_OPTION(0);
 		}
 		if (!strcmp(*argv, "help")) {
-- 
2.33.0.113.g6c40894d24

Re: [PATCH] Show patchlevel in version string

[Lawrence Velázquez]

On Fri, Sep 3, 2021, at 1:38 PM, Wesley Schwengle wrote:
> After this patch is applied, you get to see the following version string
> after you configured zsh with `--enable-custom-patchlevel=$(git describe)':
>
>   $ ./Src/zsh --version
>   zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)
>
> Signed-off-by: Wesley Schwengle <wesley@opperschaap.net>
> ---
>  Src/init.c | 6 ++++++
>  1 file changed, 6 insertions(+)

*bump*

(Apologies for the delay, Wesley.)

-- 
vq

Re: [PATCH] Show patchlevel in version string

[Axel Beckert]

Hi,

On Fri, Sep 03, 2021 at 01:38:03PM -0400, Wesley Schwengle wrote:
> Debian for example uses `debian/5.8-6+b2' as a patch level.

JFTR: That's not completely correct. Only "5.8-6" is the patch level.
"+b2" is the build counter for binary packages rebuilt from the same
source code against usually newer build-dependencies. (And "debian/"
is just the tag prefix in git, but there are never build counts like
"+b2" present in git tags in Debian.)

		Kind regards, Axel (with his Debian hat on :-)
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

Re: [PATCH] Show patchlevel in version string

[Daniel Shahaf]

Wesley Schwengle wrote on Fri, Sep 03, 2021 at 13:38:03 -0400:
> After this patch is applied, you get to see the following version string
> after you configured zsh with `--enable-custom-patchlevel=$(git describe)':
> 
>   $ ./Src/zsh --version
>   zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)

Adding the git revision there makes sense, I suppose, but why should
this only be done when that configure option is used?  The git revision
is added to ZSH_PATCHLEVEL (which is a shell variable, not an
environment variable) by default, without needing any configure flags.

Or another perspective: CUSTOM_PATCHLEVEL is used to cause
$ZSH_PATCHLEVEL to be set to something other than its default.  So, 
why shouldn't the #else branch emit the default value of $ZSH_PATCHLEVEL?

tl;dr: Why not include the (build's default) value of $ZSH_PATCHLEVEL in
the output?

Cheers,

Daniel


> Signed-off-by: Wesley Schwengle <wesley@opperschaap.net>
> ---
>  Src/init.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Src/init.c b/Src/init.c
> index 878a53a37..a04d599c3 100644
> --- a/Src/init.c
> +++ b/Src/init.c
> @@ -421,8 +421,14 @@ parseopts(char *nam, char ***argvp, char *new_opts, char **cmdp,
>  		/* GNU-style long options */
>  		++*argv;
>  		if (!strcmp(*argv, "version")) {
> +#ifdef CUSTOM_PATCHLEVEL
> +		    printf("zsh %s (%s-%s-%s/%s)\n",
> +			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE, CUSTOM_PATCHLEVEL);
> +#else
>  		    printf("zsh %s (%s-%s-%s)\n",
>  			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE);
> +#endif
> +
>  		    LAST_OPTION(0);
>  		}
>  		if (!strcmp(*argv, "help")) {
> -- 
> 2.33.0.113.g6c40894d24
> 
> 

Re: [PATCH] Show patchlevel in version string

[Wesley]

On 4/10/22 17:35, Daniel Shahaf wrote:
> Wesley Schwengle wrote on Fri, Sep 03, 2021 at 13:38:03 -0400:
>> After this patch is applied, you get to see the following version string
>> after you configured zsh with `--enable-custom-patchlevel=$(git describe)':
>>
>>    $ ./Src/zsh --version
>>    zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)
>
> Adding the git revision there makes sense, I suppose, but why should
> this only be done when that configure option is used?  The git revision
> is added to ZSH_PATCHLEVEL (which is a shell variable, not an
> environment variable) by default, without needing any configure flags.
>
> Or another perspective: CUSTOM_PATCHLEVEL is used to cause
> $ZSH_PATCHLEVEL to be set to something other than its default.  So,
> why shouldn't the #else branch emit the default value of $ZSH_PATCHLEVEL?
>
> tl;dr: Why not include the (build's default) value of $ZSH_PATCHLEVEL in
> the output?

I missed this thread, I thought it went dead after my original
submission. I didn't get the memo ;) Sorry for the delay on my part.

To answer the question: Why not for all builds? I don't think regular
release builds would include this. I borrowed the approach from git,
although they do what you are asking. Git uses GIT-VERSION-GEN[^1] in
their Makefile[^2] to include the options in their build process. I'm
not all the confident with Makefile voodoo. I just thought it was handy
for those who want it and my thought was that most developers have some
kind of custom install zsh where they can add this logic.

If you want it for every build, I would need to get some help from
someone who is sufficient at Makefiles probably. I can look into it
regardless. But my question is than, would the same approach as git
takes be ok with you?

[^1]: https://github.com/git/git/blob/master/GIT-VERSION-GEN
[^2]: https://github.com/git/git/blob/master/Makefile

--
Wesley Schwengle

Re: [PATCH] Show patchlevel in version string

[Wesley Schwengle]

On 3/31/22 03:55, Axel Beckert wrote:

> On Fri, Sep 03, 2021 at 01:38:03PM -0400, Wesley Schwengle wrote:
>> Debian for example uses `debian/5.8-6+b2' as a patch level.
>
> JFTR: That's not completely correct. Only "5.8-6" is the patch level.
> "+b2" is the build counter for binary packages rebuilt from the same
> source code against usually newer build-dependencies. (And "debian/"
> is just the tag prefix in git, but there are never build counts like
> "+b2" present in git tags in Debian.)

You kinda do :) I understand what you are saying, but it is exposed as
the patch level.

$ cat /etc/debian_version
trixie/sid

$ echo $ZSH_PATCHLEVEL
debian/5.9-4+b4

Anyways the idea is to show this outside of $ZSH_PATCHLEVEL when running
zsh --version, as I think it might be handy for those who want it.

Cheers,
Wesley

--
Wesley Schwengle
E: wesley@opndev.io

Re: [PATCH] Show patchlevel in version string

[Wesley Schwengle]

On 4/10/22 17:35, Daniel Shahaf wrote:

> Wesley Schwengle wrote on Fri, Sep 03, 2021 at 13:38:03 -0400:
>> After this patch is applied, you get to see the following version string
>> after you configured zsh with `--enable-custom-patchlevel=$(git describe)':
>>
>>    $ ./Src/zsh --version
>>    zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)
>
> Adding the git revision there makes sense, I suppose, but why should
> this only be done when that configure option is used?  The git revision
> is added to ZSH_PATCHLEVEL (which is a shell variable, not an
> environment variable) by default, without needing any configure flags.
>
> Or another perspective: CUSTOM_PATCHLEVEL is used to cause
> $ZSH_PATCHLEVEL to be set to something other than its default.  So,
> why shouldn't the #else branch emit the default value of $ZSH_PATCHLEVEL?
>
> tl;dr: Why not include the (build's default) value of $ZSH_PATCHLEVEL in
> the output?

I want to back track a little from my original answer from last Friday.

How do we progress, this patch in itself could be merged I think without
having to have all kinds of other logic to always show it. I think this
is a nice first step. I'm willing to work on the other solution to
always include a patch level based on some other logic.

However I placed the patch level between the brackets because I wasn't
sure if/how we want to display the version. As stated in the commit body
of the patch:

> Because I'm not aware how downstream deals with a difference in version
> strings I've decided to add it to the vendor/os type bit. Debian for
> example uses `debian/5.8-6+b2' as a patch level. This would probably
> break scripts which expect `zsh x.y.z' if the patch level replaced the
> ZSH_VERSION string.

$ zsh --version
zsh 5.9 (x86_64-debian-linux-gnu)

I would expect (or assume) that Debian wants to keep showing the 5.9
version and not the debian/5.9-4+b4 bit. This would make parsing the ZSH
version tricky, eg, zsh --version | awk '{print $2}' suddenly gives a
different output than scripts would expect.

If you run zsh --version from a bash shell you get the version string,
you don't have access to the $ZSH_VERSION shell variable.

Now, if we use this ZSH_PATCHLEVEL in any build, what logic are we going
to apply?

* Do we remove the CUSTOM_PATCHLEVEL output from the --version call if
the CUSTOM_PATCHLEVEL equals the ZSH_VERSION string?

* Do we replace the ZSH_VERSION with the CUSTOM_PATCHLEVEL if the
ZSH_VERSION includes -dev, eg 5.9.0.1-dev becomes 5.9-240-g51ae2a5ff

To reiterate. I'm open to add improvements to always displaying the
patch level, but I would love to see this patch merged before we agree
on more things. I think adding it to the OS/Vendor bit has very little
impact on scripts but it aids us in seeing what is being used (for
example when build from source).

Cheers,
Wesley

--
Wesley Schwengle
E: wesley@opndev.io