From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling Date: Fri, 7 Nov 2014 14:30:58 +0100 Message-ID: <20141107133058.GA11146@aepfle.de> 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> <1415099037.11486.25.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1415099037.11486.25.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: George Dunlap , Ian Jackson , Stefano Stabellini , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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 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... >