Use bash patchlevel as part of RPM version?

[Callum Lerwick]

On Tue, 2009-04-21 at 21:53 +0300, Axel Thimm wrote:
> On Tue, Apr 21, 2009 at 01:02:50PM -0500, Callum Lerwick wrote:
> > But putting the patchlevel in somewhere isn't a bad idea. I'd go with
> > something like this:
> > 
> > bash-4.0-1.pl16
> > bash-4.0-2.pl17
> > bash-4.0-3.pl18
> 
> So what would you do when upstream does consider releasing
> bash-4.0.25.tar.gz, then again just uses patchlevels for say up to
> bash-4.0.33.tar.gz, then goes bash-4.2.tar.gz and the story begins
> anew?

Your description sounds like this to me:

bash-4.0.25-1
bash-4.0.25-2.pl1
bash-4.0.25-3.pl2
bash-4.0.33-1
bash-4.2-1
bash-4.2-2.pl1

etc.

> Technically following the guidelines to the letter we would get
> 
> bash-4.0-3.pl18
> ...
> bash-4.0-4.pl24
> bash-4.0.25-1
> bash-4.0-1.pl26 (epoch bump!)
> ...
> bash-4.0-6.pl32
> bash-4.0.33-1
> bash-4.0-1.pl34 (again epoch bump!)

Is that what you were trying to describe? If they do this, upstream
should be slapped with a herring for using completely senseless release
versioning.

How is a *human* even supposed to know that 4.0 patchlevel 26 is newer
than 4.0.25?

In this hypothetical insanity, it would be *upstreams* fault for us
having to use epochs, not our fault and not a fault in our guidelines.

> The official patches by upstream do intenionally increase the version
> of the source and bash --version reflects that. So upstream's
> intention is that this source conglomeration is bash-4.0.17, not
> bash-4.0 with some patches.

Interesting.

No, upstream's intention is not clear. The tarball versioning and
internal versioning conflict This is a case where upstream is being
unclear and we simply need to communicate with them to sort things out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090421/a6c2dc7a/attachment.sig>