Use bash patchlevel as part of RPM version?

[Ralf Corsepius]

Axel Thimm wrote:
> 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. http://fedoraproject.org/wiki/PackageNamingGuidelines#Package_Version
>>
>> 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.

>> 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
> 
> ftp://ftp.cwru.edu/pub/bash/bash-3.0.16.tar.gz
> ftp://ftp.cwru.edu/pub/bash/bash-3.2.48.tar.gz
> 
> It's a strange release policy,
ACK, ...

> but upstream does seem to version with
> three numbers, so using 4.0.17 in rpm's version field seems to make
> sense.
Well, in this case, it would be appropriate to contact upstream and to 
ask them why they don't release tarballs, rsp. about their plans on 
their next release's version number.

> (BTW it is not defining bash's version, but even wikipedia shows
> bash's version to be 4.0.17: http://en.wikipedia.org/wiki/Bash)
Wikipedia, ... ;-)

Ralf