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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.02.2025 01:51, Andrew Cooper wrote:
> 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@xxxxxxx>
> 
> 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.

Just for my understanding - may I ask why this editing is necessary?
Other release technicians never mentioned the (indeed undesirable)
need to do so.

> 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.

Sure, if it truly is getting in the way, then it needs re-considering.
Just to mention it: Then the question is going to be though whether
really to merely adjust XEN_EXTRAVERSION, or whether instead to do
this consistently in all (three?) places.

Jan