On 13.02.2025 20:09, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Jan Beulich wrote:
>> 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.stabell...@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.
>>
>> Just for my understanding - may I ask why this editing is necessary?
>> Other release technicians never mentioned the (indeed undesirable)
>> need to do so.
> 
> This is not an answer to Jan's question, more me highlighting
> priorities.
> 
> While having the appropriate RC version in the Xen name during the RC
> phase of the release process would be nice, I do not believe it is
> mandatory. We do need it in the official release tarballs though.
> 
> So the most important consideration for me is making the release
> technician's job easier and less error-prone. Therefore, I believe we
> should follow Andrew and Julien's recommendation on this.
> 
> Andrew, just to be clear, are you recommending to go with a patch
> similar to the one I posted, and then update the XEN_VENDORVERSION
> with a new commit every time there is a new RC? Or are you suggesting
> something else? I wasn't certain reading your reply.

Just one point here: I don't think we ought to be playing with
XEN_VENDORVERSION. If we switch, we ought to switch back to how it
was long ago - the RC number being part of XEN_EXTRAVERSION.
XEN_VENDORVERSION really should be left to vendors.

Jan

Reply via email to