Use bash patchlevel as part of RPM version?

Axel Thimm Axel.Thimm at
Tue Apr 21 09:38:32 UTC 2009

On Tue, Apr 21, 2009 at 10:26:42AM +0200, Ralf Corsepius wrote:
> Roman Rakus wrote:
>> Hi,
>> There is a bug (#496780) requesting to use patchlevel of bash as part 
>> of RPM version. So today bash-4.0-6.fc11.i586 would be  
>> bash-4.0.16-6.fc11.i586. What do you think about it?
> It's a bad idea.
> c.f.
> Rule of thumb: Try to let an rpm's version match with upstream's version  
> whenever possible, otherwise you're very likely to meet conflicts with  
> upstream's versioning.
>> Could it break anything? 
> Well, not actually break, but you (rsp. the Fedora package maintainer)  
> are not unlikely to hit NEVR issues with upstream.
> E.g. with your proposal you would be in trouble if upstream decides to  
> release 4.0.1 - You have to bump epoch: etc.

Upstream already uses the patchlevel in their versioning, e.g.

# bash --version
GNU bash, version 4.0.16(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

> My recommendation: Either ignore upstream's patch-level in an rpm's NEVR  
> and use your own NEVR scheme, or try to incorporate upstream's  
> "patch-levels" into an rpm's %release, if you "feel like it".
> I would not do so.

Note that there were a couple normal release tarballs like

It's a strange release policy, but upstream does seem to version with
three numbers, so using 4.0.17 in rpm's version field seems to make

(BTW it is not defining bash's version, but even wikipedia shows
bash's version to be 4.0.17:
Axel.Thimm at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : 

More information about the devel mailing list