Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Nov 3, 2014 at 2:16 PM, George Dunlap
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Tue, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@xxxxxxxxx> wrote:
>> An increasing version and/or release number helps to update existing
>> packages without --force as in "rpm Uvh --force xen.rpm". Instead its
>> possible to do "rpm -Fvh *.rpm" to update only already installed
>> packages.
>>
>> With the current way of calculating version-release it is difficult to
>> get an increasing release number into the spec file. The release is
>> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
>> which has the bad side effect that xen.gz always gets a different
>> filename every time.
>>
>> Since the value of release has no meaning its fine to have an ever
>> increasing number. This could be either the number of seconds (+%s), or
>> some representation which could mean something to a human. The change
>> uses a representation of date+time.
>>
>> With this change my xen$PKG_SUFFIX.rpm gets as version-release
>> 4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.
>>
>> Note: to maintain the functionality that "rpm -F xen.rpm" works its also
>> required that the alphanumerical chars increase. Unfortunately thats not
>> the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
>> from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
>> is nothing we can do about this part.
>> Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
>> is smaller than "r" in 4.6-rcN. But thats a different discussion.
>>
>> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
>> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>> Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>> ---
>>  tools/misc/mkrpm | 12 +++++-------
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
>> index 9b8c6d9..b54de24 100644
>> --- a/tools/misc/mkrpm
>> +++ b/tools/misc/mkrpm
>> @@ -13,13 +13,11 @@ fi
>>
>>  xenroot="$1"
>>
>> -# rpmbuild doesn't like dashes in the version; break it down into
>> -# version and release.  Default to "0" if there isn't a release.
>> -v=(${2/-/ })
>> -version=${v[0]}
>> -release=${v[1]}
>> -
>> -[[ -n "$release" ]] || release="0"
>> +# rpmbuild doesn't support dashes in the version;
>> +version=${2//-/_}
>> +# Use an ever increasing release number for this devel pkg.
>> +# This makes sure rpm -Fvh xen$PKG_SUFFIX.rpm can be updated wihtout 
>> --force.
>> +release="`date +%Y%m%d%H%M%S`"
>
> Hrm, I can see how this might be useful, but I'm not really a fan of
> the uniquifier being based on the date the build was actually kicked
> off.

Given that these are also just supposed to be used by developers,
requiring you to do "rpm -e xen" first doesn't seem like *that* much
of a big deal.  It's easy enough to put into a script.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel