[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Use bash patchlevel as part of RPM version?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]