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

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

[Olaf Hering]

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@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
---
 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`"
 
 cd $xenroot

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

[Olaf Hering]

On Tue, Oct 07, Olaf Hering wrote:

> always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,

This should have been "make rpmball ...".


Olaf

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

[Olaf Hering]

Ping?

On Tue, Oct 07, Olaf Hering 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@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  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`"
>  
>  cd $xenroot
>  

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

[George Dunlap]

On Wed, Oct 29, 2014 at 8:17 AM, Olaf Hering <olaf@aepfle.de> wrote:
> Ping?

Sorry, I thought you had found an error and were going to resubmit.
:-)  I'll take a look at it today.

 -George

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

[George Dunlap]

On Tue, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> 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@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  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

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

[George Dunlap]

On Mon, Nov 3, 2014 at 2:16 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Oct 7, 2014 at 4:01 PM, Olaf Hering <olaf@aepfle.de> 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@aepfle.de>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
>> ---
>>  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

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

[Olaf Hering]

On Mon, Nov 03, George Dunlap wrote:

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

Very difficult, because one does changes without commit, runs 'make
rpmball' and expects that rpm -Fvh *.rpm continues to work.


Olaf

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

[Ian Campbell]

On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
> 
> > How difficult would it be to have this be something sensible like,
> > "changesets since last tag"?
> 
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Isn't that what "rpm -Uvh" is for?

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

[George Dunlap]

On 11/03/2014 02:24 PM, Olaf Hering wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> How difficult would it be to have this be something sensible like,
>> "changesets since last tag"?
> Very difficult, because one does changes without commit, runs 'make
> rpmball' and expects that rpm -Fvh *.rpm continues to work.

Right.  Personally, I think trying to make "rpm -Fvh" work for all the 
use cases a developer might want is more hassle than it's worth; as I 
said, I have scripts that just do "rpm -e" in such cases.  I wouldn't 
oppose it, but I don't really support it either.

Ian / Ian / Wei, any thoughts?

  -George

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

[Olaf Hering]

On Mon, Nov 03, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > On Mon, Nov 03, George Dunlap wrote:
> > 
> > > How difficult would it be to have this be something sensible like,
> > > "changesets since last tag"?
> > 
> > Very difficult, because one does changes without commit, runs 'make
> > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Isn't that what "rpm -Uvh" is for?

No, thats for fresh install. -F installs whats already there.

Olaf

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

[Olaf Hering]

On Mon, Nov 03, George Dunlap wrote:

> On 11/03/2014 02:24 PM, Olaf Hering wrote:
> >On Mon, Nov 03, George Dunlap wrote:
> >
> >>How difficult would it be to have this be something sensible like,
> >>"changesets since last tag"?
> >Very difficult, because one does changes without commit, runs 'make
> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
> 
> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
> cases a developer might want is more hassle than it's worth; as I said, I
> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
> I don't really support it either.

What exactly is the hassle here?! Its just some number for the sake of
rpm.

Olaf

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

[Ian Campbell]

On Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:
> On Mon, Nov 03, Ian Campbell wrote:
> 
> > On Mon, 2014-11-03 at 15:24 +0100, Olaf Hering wrote:
> > > On Mon, Nov 03, George Dunlap wrote:
> > > 
> > > > How difficult would it be to have this be something sensible like,
> > > > "changesets since last tag"?
> > > 
> > > Very difficult, because one does changes without commit, runs 'make
> > > rpmball' and expects that rpm -Fvh *.rpm continues to work.
> > 
> > Isn't that what "rpm -Uvh" is for?
> 
> No, thats for fresh install.

Isn't that -ivh?

>  -F installs whats already there.

Does rpm --force -Fvh not work?

Ian.

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

[Olaf Hering]

On Tue, Nov 04, Ian Campbell wrote:

> On Mon, 2014-11-03 at 15:47 +0100, Olaf Hering wrote:

> Isn't that -ivh?

-i installs multiple packages, if they have no overlapping files. -U
replaces every installed version with the new one.

> >  -F installs whats already there.
> Does rpm --force -Fvh not work?

-F behaves different. I think it would not take --force into account. At
least --oldpackage does not work with -F.


Olaf

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

[George Dunlap]

On Mon, Nov 3, 2014 at 2:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 03, George Dunlap wrote:
>
>> On 11/03/2014 02:24 PM, Olaf Hering wrote:
>> >On Mon, Nov 03, George Dunlap wrote:
>> >
>> >>How difficult would it be to have this be something sensible like,
>> >>"changesets since last tag"?
>> >Very difficult, because one does changes without commit, runs 'make
>> >rpmball' and expects that rpm -Fvh *.rpm continues to work.
>>
>> Right.  Personally, I think trying to make "rpm -Fvh" work for all the use
>> cases a developer might want is more hassle than it's worth; as I said, I
>> have scripts that just do "rpm -e" in such cases.  I wouldn't oppose it, but
>> I don't really support it either.
>
> What exactly is the hassle here?! Its just some number for the sake of
> rpm.

A number based on the time you happened to create the RPM, not based
on something intrinsic about the content of the RPM; that just seems
kind of hacky to me.  It happens to work well for your common
workflow, but you can certainly imagine other workflows or other
situations where you'd have to more manually override things anyway
(for instance, doing bisections, or comparing functionality in
different releases).  It seems like rather than having to remember
when you can skip the manual override bits, and when you can't, it
would be better to just use them all the time.

Anyway, like I said, I won't argue against it.  I have no technical
objections to the patch; it seems to do what it says on the tin.  I'll
leave it for the maintainers to decide what they think about the
functionality.

 -George

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

[Olaf Hering]

On Tue, Nov 04, George Dunlap wrote:

> A number based on the time you happened to create the RPM, not based
> on something intrinsic about the content of the RPM; that just seems
> kind of hacky to me.  It happens to work well for your common
> workflow, but you can certainly imagine other workflows or other
> situations where you'd have to more manually override things anyway
> (for instance, doing bisections, or comparing functionality in
> different releases).  It seems like rather than having to remember
> when you can skip the manual override bits, and when you can't, it
> would be better to just use them all the time.

George, the release number is and was never meant to describe the
content of a package. It just means "its different". And it will even
work for bisect because the package is always "newer", even if the
content is different.

And after commit b8ebc6b9e07d3cc061fdded1a0530bd6b25d4634 ("tools/mkrpm:
allow custom rpm package name") and all the --prefix changes its easy to
have independent packages for every branch.

Olaf

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

[George Dunlap]

On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Nov 04, George Dunlap wrote:
>
>> A number based on the time you happened to create the RPM, not based
>> on something intrinsic about the content of the RPM; that just seems
>> kind of hacky to me.  It happens to work well for your common
>> workflow, but you can certainly imagine other workflows or other
>> situations where you'd have to more manually override things anyway
>> (for instance, doing bisections, or comparing functionality in
>> different releases).  It seems like rather than having to remember
>> when you can skip the manual override bits, and when you can't, it
>> would be better to just use them all the time.
>
> George, the release number is and was never meant to describe the
> content of a package. It just means "its different". And it will even
> work for bisect because the package is always "newer", even if the
> content is different.

Not if you end up going to a previously built package for some reason.

I can see how this makes more sense if you do have an independent
package installed for every branch; but most people are not going to
do that.

Anyway, if I were a maintainer, I might decide to accept it, even
though I didn't like it, on the grounds that it doesn't do much harm
and somebody finds it useful.

Since I'm not a maintainer, I'm free to be opinionated. :-)

 -George

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

[Ian Campbell]

On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, Nov 04, George Dunlap wrote:
> >
> >> A number based on the time you happened to create the RPM, not based
> >> on something intrinsic about the content of the RPM; that just seems
> >> kind of hacky to me.  It happens to work well for your common
> >> workflow, but you can certainly imagine other workflows or other
> >> situations where you'd have to more manually override things anyway
> >> (for instance, doing bisections, or comparing functionality in
> >> different releases).  It seems like rather than having to remember
> >> when you can skip the manual override bits, and when you can't, it
> >> would be better to just use them all the time.
> >
> > George, the release number is and was never meant to describe the
> > content of a package. It just means "its different". And it will even
> > work for bisect because the package is always "newer", even if the
> > content is different.
> 
> Not if you end up going to a previously built package for some reason.
> 
> I can see how this makes more sense if you do have an independent
> package installed for every branch; but most people are not going to
> do that.
> 
> Anyway, if I were a maintainer, I might decide to accept it, even
> though I didn't like it, on the grounds that it doesn't do much harm
> and somebody finds it useful.
> 
> Since I'm not a maintainer, I'm free to be opinionated. :-)

I don't think any of the formal maintainers of this code use RPM[0], and
you are the original author of the tool... So I'm afraid I think you
might have a more relevant opinion than you might like.

Ian.

[0] At least half happen to be Debian Maintainers...

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

[Olaf Hering]

So how should we proceed here?!

Olaf

On Tue, Nov 04, Ian Campbell wrote:

> On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Tue, Nov 04, George Dunlap wrote:
> > >
> > >> A number based on the time you happened to create the RPM, not based
> > >> on something intrinsic about the content of the RPM; that just seems
> > >> kind of hacky to me.  It happens to work well for your common
> > >> workflow, but you can certainly imagine other workflows or other
> > >> situations where you'd have to more manually override things anyway
> > >> (for instance, doing bisections, or comparing functionality in
> > >> different releases).  It seems like rather than having to remember
> > >> when you can skip the manual override bits, and when you can't, it
> > >> would be better to just use them all the time.
> > >
> > > George, the release number is and was never meant to describe the
> > > content of a package. It just means "its different". And it will even
> > > work for bisect because the package is always "newer", even if the
> > > content is different.
> > 
> > Not if you end up going to a previously built package for some reason.
> > 
> > I can see how this makes more sense if you do have an independent
> > package installed for every branch; but most people are not going to
> > do that.
> > 
> > Anyway, if I were a maintainer, I might decide to accept it, even
> > though I didn't like it, on the grounds that it doesn't do much harm
> > and somebody finds it useful.
> > 
> > Since I'm not a maintainer, I'm free to be opinionated. :-)
> 
> I don't think any of the formal maintainers of this code use RPM[0], and
> you are the original author of the tool... So I'm afraid I think you
> might have a more relevant opinion than you might like.
> 
> Ian.
> 
> [0] At least half happen to be Debian Maintainers...
> 

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

[Konrad Rzeszutek Wilk]

On Fri, Nov 07, 2014 at 02:30:58PM +0100, Olaf Hering wrote:
> So how should we proceed here?!

George, any input on this since Ian just nominated you to
be the maintainer-pro-temp?

Thanks.
> 
> Olaf
> 
> On Tue, Nov 04, Ian Campbell wrote:
> 
> > On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > > On Tue, Nov 04, George Dunlap wrote:
> > > >
> > > >> A number based on the time you happened to create the RPM, not based
> > > >> on something intrinsic about the content of the RPM; that just seems
> > > >> kind of hacky to me.  It happens to work well for your common
> > > >> workflow, but you can certainly imagine other workflows or other
> > > >> situations where you'd have to more manually override things anyway
> > > >> (for instance, doing bisections, or comparing functionality in
> > > >> different releases).  It seems like rather than having to remember
> > > >> when you can skip the manual override bits, and when you can't, it
> > > >> would be better to just use them all the time.
> > > >
> > > > George, the release number is and was never meant to describe the
> > > > content of a package. It just means "its different". And it will even
> > > > work for bisect because the package is always "newer", even if the
> > > > content is different.
> > > 
> > > Not if you end up going to a previously built package for some reason.
> > > 
> > > I can see how this makes more sense if you do have an independent
> > > package installed for every branch; but most people are not going to
> > > do that.
> > > 
> > > Anyway, if I were a maintainer, I might decide to accept it, even
> > > though I didn't like it, on the grounds that it doesn't do much harm
> > > and somebody finds it useful.
> > > 
> > > Since I'm not a maintainer, I'm free to be opinionated. :-)
> > 
> > I don't think any of the formal maintainers of this code use RPM[0], and
> > you are the original author of the tool... So I'm afraid I think you
> > might have a more relevant opinion than you might like.
> > 
> > Ian.
> > 
> > [0] At least half happen to be Debian Maintainers...
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel