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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel