From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 1/5] tools/mkrpm: improve version.release handling Date: Mon, 23 Mar 2015 16:15:58 +0000 Message-ID: <55103C3E.3000302@eu.citrix.com> References: <1426872279-5001-1-git-send-email-olaf@aepfle.de> <1426872279-5001-2-git-send-email-olaf@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1426872279-5001-2-git-send-email-olaf@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering , xen-devel@lists.xen.org Cc: Wei Liu , Ian Jackson , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 03/20/2015 05:24 PM, 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. > > The usage of --force disables essentials checks such as file conflict > detection. As a result the new xen.rpm may overwrite files owned by > other 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. > > Signed-off-by: Olaf Hering > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Stefano Stabellini > Cc: Wei Liu > Cc: George Dunlap Hey Olaf, Sorry for not getting back to you with this before. I applied this patch, and the name came out looking like this: xen-4.6_unstable-20150323160547.x86_64.rpm I'm not really happy with having the massive number show up automatically when anyone makes an rpm. What would you think about adding a variable where you could set this as part of the build process? e.g., XEN_RPM_RELEASE="$(date +%Y%m%d%H%M%S)" make rpmball -George > --- > 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 > >