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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

How difficult would it be to have this be something sensible like,
"changesets since last tag"?

This information can be found, for instance, in "git describe"; for example:

$ git describe
4.5.0-rc1-44-g82587ce

(i.e., 44 commits pas 4.5.0-rc1)

$ git checkout 91086d0
$ git describe
4.5-unstable-1495-g91086d0

(i.e., 1495 commits past 4.5-unstable)

If git isn't present, then it's probably a source tarball, in which
case "0" is probably a suitable value.

Thoughts?

 -George

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