Re: [BUG?] Wrong RC reported during 'make install'

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
> On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
>> Hello everyone,
>>
>> During the installation of Xen on an ARM server machine from the source code,
>> I found that the wrong release candidate (rc) is being used:
>>   $ make install  
>>     install -m0644 -p xen //boot/xen-4.20-rc  
>>     install: cannot remove ‘//boot/xen-4.20-rc’: Permission denied  
>>     make[1]: *** [Makefile:507: _install] Error 1
>> My expectation is that it should be xen-4.20-rc4.
>>
>> I'm not sure if this behavior is intentional or if users are expected to set
>> the XEN_VENDORVERSION variable manually to ensure the correct release
>> candidate number.
>>
>> In my opinion, we should set the proper release candidate number after
>> "xen-4.20-rc" automatically.
>>
>> Does anyone have any thoughts or suggestions on how to resolve this issue?
> Hi Oleksii,
>
> I did a quick test and I see exactly the same on x86 as well. This patch
> fixes it, but then it would need someone to update the RC number in
> xen/Makefile every time a new RC is made.
>
> ---
> xen: add RC version number to xen filename
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

This is a direct consequence of the request to keep XEN_EXTRAVERSION at
"-rc" throughout the release cycle.

I'm having to manually edit that simply to create the tarballs
correctly, which in turn means that the tarball isn't a byte-for-byte
identical `git archive` of the tag it purports to be.

I'd not twigged that it mean the builds from the tarballs reported false
information too.

While I appreciate the wish to not have a commit per RC bumping
XEN_EXTRAVERSION, I think the avoidance of doing so is creating more
problems than it solves, and we should revert back to the prior way of
doing things.

~Andrew