Use bash patchlevel as part of RPM version?

[Axel Thimm]

On Tue, Apr 21, 2009 at 02:45:51PM -0500, Callum Lerwick wrote:
> 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.

No, there is no forth part on the version, we are always talking about
the third version component. E.g. in the current version of bash,
4.0.17, the "17" is the patchlevel.

Or if you want to use bash-4.0.25-2.pl1 for bash-4.0 and the first 26
patchlevels and version it that way because there happened to be a
tarball release at 4.0.25, then the package versioning is really
borked. Which user on earth would consider adding the number after
your "pl" to the 3rd part of the version to find the true version of
the package?

> > 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.

No, that's not what I suggest, I just outline what the blind following
of the guidelines would produce (IFF the patchlevel were NON-NUMERIC,
which it isn;t and we shouldn't suggest it is).

> 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.

I disagree, we are packagers, not blind. Just use bash --version on
you favourite system and then let me know how you would package this
bash. You would arrive at the conventional scheme:

bash-4.0.17-1
bash-4.0.18-1
bash-4.0.19-1
...
bash-4.0.25-1
bash-4.0.26-1
...

> > 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.

Why is there a conflict? The original tarball had a certain
version. With every patch came a version bump. Since bash "releases"
_very_ often the patches are sometimes a one-liner. Pushing out a
whole tarball for a change of a few bytes seems like a waste of mirror
resources, so upstream just publishes the diffs. And every now and
then they republish a whole tarball. Where is the crime?

There is no difference to the kernel's diffs for version 2.6.29 to
2.6.29.1 like `patch-2.6.29.1.bz2'. Only that the kernel also releases
a whole tarball as well, there are usually more changes than a
one-liner with the kernel.

If you don't trust me, check for yourself, or ask upstream, but it is
rather crystal clear.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090422/032b5d4e/attachment.bin