From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling Date: Tue, 4 Nov 2014 11:03:57 +0000 Message-ID: <1415099037.11486.25.camel@citrix.com> References: <1412694063-29616-1-git-send-email-olaf@aepfle.de> <20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com> <20141103144848.GB28870@aepfle.de> <20141104104649.GA8479@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Jackson , Olaf Hering , Stefano Stabellini , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote: > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering 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...