rust: Add release description

[filnet]

fixes #12569

[1480c1]

It might be better to match this closer to the output of gcc --version that we have with the whole Build by MSYS2 project, unless this component is something that's expected to be grepable or parsed in some way.

I do see that rustc --version (managed via rustup as far as I remember) on my linux box shows

rustc --version
rustc 1.61.0 (fe5b13d68 2022-05-18)

but I don't think the commit hash really matters for us since we are using a tarball rather than a checkout

[Zapeth]

but I don't think the commit hash really matters for us since we are using a tarball rather than a checkout

rustc currently just includes basic version information when built via tarball (ie no commit hash and no commit date), but there is a pending PR that addresses this -> rust-lang/rust#100557

[filnet]

Tell me what you want. I have no opinion.

[filnet]

The description can be any string.
The string can contain these variables ${MINGW_PACKAGE_PREFIX} ${_realname} ${pkgver} ${pkgrel}.

[1480c1]

Perhaps something like,

rustc --version
rustc 1.62.1 (2022-08-17 Built by MSYS2 project)

or exposing which subsystem it was built for along with date and ownership

rustc --version
rustc 1.62.1 (mingw64 Rev${pkgrel} 2022-08-17 Built by MSYS2 project)

or somehow (I don't think moving the version to the end is possible) to bring it closer to gcc.exe --version while retaining the date (don't know if we want to if we are aiming for reproducible builds)

rustc --version
rustc (Rev${pkgrel}, Built by MSYS2 project on 2022-08-17) 1.62.1

Just some ideas on how to put some things together, but I would say it's based on how easy it is to put them there, we probably want to convey the fact that this build is specifically from msys2 rather than an official build from the Rust Language organization for Windows so that way upstream devs can except that it might not be "pristine" and could have additional patches on top of it.

[filnet]

I can do exactly like gcc:

$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 12.1.0

Without a date. Threre is no readily available date variable afaik.

[mmuetzel]

Threre is no readily available date variable afaik.

You could maybe use date +%Y-%m-%d (or $(date +%Y-%m-%d) inside a shell script) to construct the date when the package was built.
I.e., something along this:

-    --release-description="Rev${pkgrel}, Built by MSYS2 project" \
+    --release-description="Rev${pkgrel}, Built by MSYS2 project on $(date +%Y-%m-%d)" \

[filnet]

Do we really want the date ? gcc does not have it.

[Zapeth]

I don't think date would be that useful, especially since that information should be somewhat tied to ${pkgrel} and could be looked up if necessary.

As for possibly including subsystem information, are there any patches that are only applied to a specific subsystem? If yes then it might be worth including, though I guess the subsystem information could also be derived from the executable itself.

But these are just my two cents, I mainly brought up this issue to point out the fact that the release description is currently empty, so I don't have any particular preference what that description should look like,

[mati865]

I don't know if reproducible builds are a thing for us but many distros stopped inserting dates because it's not easily reproducible.

[lazka]

I don't know if reproducible builds are a thing for us but many distros stopped inserting dates because it's not easily reproducible.

The reproducible builds way would be https://reproducible-builds.org/docs/source-date-epoch/#bash--posix-shell

[lazka]

Let's merge the minimal version, until some has an actual use case for more information.