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: Tue, 4 Nov 2014 11:46:49 +0100 Message-ID: <20141104104649.GA8479@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: Wei Liu , "xen-devel@lists.xen.org" , Ian Jackson , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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