Use bash patchlevel as part of RPM version?
seg at haxxed.com
Tue Apr 21 19:45:51 UTC 2009
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
Your description sounds like this to me:
> Technically following the guidelines to the letter we would get
> bash-4.0-1.pl26 (epoch bump!)
> 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
How is a *human* even supposed to know that 4.0 patchlevel 26 is newer
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.
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: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090421/a6c2dc7a/attachment.bin
More information about the devel