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? Could it break anything? RR
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.
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.
Ralf
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.
# bash --version GNU bash, version 4.0.16(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
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, but upstream does seem to version with three numbers, so using 4.0.17 in rpm's version field seems to make sense.
(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)
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
Ralf Corsepius wrote:
Axel Thimm wrote:
On Tue, Apr 21, 2009 at 10:26:42AM +0200, Ralf Corsepius wrote:
Roman Rakus wrote:
(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, ... ;-)
FWIW: bash's home-page http://tiswww.case.edu/php/chet/bash/bashtop.html in http://tiswww.case.edu/php/chet/bash/bashtop.html#TOCCurrentStatus says "The current version of bash is bash-4.0."
Ralf
Ralf Corsepius wrote:
Ralf Corsepius wrote:
Axel Thimm wrote:
On Tue, Apr 21, 2009 at 10:26:42AM +0200, Ralf Corsepius wrote:
Roman Rakus wrote:
(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, ... ;-)
FWIW: bash's home-page http://tiswww.case.edu/php/chet/bash/bashtop.html in http://tiswww.case.edu/php/chet/bash/bashtop.html#TOCCurrentStatus says "The current version of bash is bash-4.0."
Ralf
The truth is that upstream versions bash in two number (4.0), but in some cases provides tarball with applied patches and uses three numbers. In fedora we use two numbered version and patch it. What about this NEVR: bash-4.0-p16-6.fc11.i586 where p16 stands for patchlevel 16. If not, I will close bug as notabug... RR
Axel Thimm wrote:
On Tue, Apr 21, 2009 at 01:56:22PM +0200, Roman Rakus wrote:
What about this NEVR: bash-4.0-p16-6.fc11.i586 where p16 stands for patchlevel 16.
You cannot have a hyphen in the version or the release tag, the above is malformed.
Ah, yes... maybe as it is proposed in bugzilla: bash-4.0.16-6.fc11.i586 And in next patch level: e.g. bash-4.0.24-1.fc11.i586 RR
On Tue, 2009-04-21 at 14:23 +0200, Roman Rakus wrote:
Ah, yes... maybe as it is proposed in bugzilla: bash-4.0.16-6.fc11.i586 And in next patch level: e.g. bash-4.0.24-1.fc11.i586
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Post-Release_packa...
You would want to do bash-4.0-6.16.fc11 followed by bash-4.0-7.24.fc11
Basically following bash-4.0-X.PatchLevel%{?dist}
The X is in int that keeps on increasing as you do more releases, the patch level is your posttag.
Jesse Keating wrote:
On Tue, 2009-04-21 at 14:23 +0200, Roman Rakus wrote:
Ah, yes... maybe as it is proposed in bugzilla: bash-4.0.16-6.fc11.i586 And in next patch level: e.g. bash-4.0.24-1.fc11.i586
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Post-Release_packa...
You would want to do bash-4.0-6.16.fc11 followed by bash-4.0-7.24.fc11
Basically following bash-4.0-X.PatchLevel%{?dist}
The X is in int that keeps on increasing as you do more releases, the patch level is your posttag.
Thank you all guys. RR
On Tuesday 21 April 2009, Axel Thimm wrote:
On Tue, Apr 21, 2009 at 01:56:22PM +0200, Roman Rakus wrote:
What about this NEVR: bash-4.0-p16-6.fc11.i586 where p16 stands for patchlevel 16.
You cannot have a hyphen in the version or the release tag, the above is malformed.
But without the hyphen it would work for the expected cases, although probably not be packaging guidelines "compliant":
$ rpmdev-vercmp 4.0-1 4.0p16-1 0:4.0p16-1 is newer
$ rpmdev-vercmp 4.0p17-1 4.0p16-1 0:4.0p17-1 is newer
$ rpmdev-vercmp 4.0p17-1 4.0.1-1 0:4.0.1-1 is newer
$ rpmdev-vercmp 4.0p17-1 4.01-1 0:4.01-1 is newer
Cases like 4.0a that should be treated as newer than 4.0p* would require either use of Epochs or doing something strange like inventing zeros:
$ rpmdev-vercmp 4.0p17-1 4.0a-1 0:4.0p17-1 is newer
$ rpmdev-vercmp 4.0p17-1 4.0.0a-1 0:4.0.0a-1 is newer
$ rpmdev-vercmp 4.0p17-1 4.0.0-1.a 0:4.0.0-1.a is newer
2009/4/21 Roman Rakus rrakus@redhat.com:
The truth is that upstream versions bash in two number (4.0), but in some cases provides tarball with applied patches and uses three numbers. In fedora we use two numbered version and patch it.
So, you could (should?) use bash-4.0-31.p39%{?dist}, see http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Post-Release_packag....
On Tue, Apr 21, 2009 at 09:02:09AM +0200, 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? Could it break anything? RR
Since bash doesn't have any fancy provides try something like
for package in `repoquery --whatrequires bash`; do echo $package; repoquery -R $package|grep bash; done
to check what dependencies are pointing to bash's version. I think it looks quite safe, but OTOH we're in a freeze with bash being an important package, so it's better to change it for >= F12 or at the very least as an update to 4.0.17 later in F11's maintenance timeline.
On Tue, 2009-04-21 at 09:02 +0200, 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? Could it break anything? RR
General rule of thumb is follow what's in the tarball filename if possible. And the patchlevel isn't in it.
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
... That is, follow the guidelines for a non-numeric post release:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Version
(Even though it's technically numeric...)
On Tue, Apr 21, 2009 at 01:02:50PM -0500, Callum Lerwick wrote:
On Tue, 2009-04-21 at 09:02 +0200, Roman Rakus wrote:
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? Could it break anything? RR
General rule of thumb is follow what's in the tarball filename if possible. And the patchlevel isn't in it.
The release process model of bash is "lazy", they only release a full tarball if the diffs are large enough (or the accumulated sum of them).
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?
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!)
Guidelines and laws can be interpreted in many ways, but even in court the intention of the law is important - the post-release versioning for *NON-NUMERIC* patchlevels, which BTW is here not the case, bash upstream never adds a "p" or any other letter) serves for keeping sane upgrade paths w/o introducing new epochs and if we were to follow it to the letter we would indeed achive the opposite.
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.
I'd say either add the patchlevel to the version like the bugzilla requests it (because that's were it belongs, the stuff-it-as-as-suffix-to-the-release-tag workaround is just a ... workaround), or leave it as it is.
Whatever the outcome, for F11's release I wouldn't touch bash anymore. If there is something to fix do it as an update, or for F12.
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.
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.
On Wed, 2009-04-22 at 08:22 +0300, Axel Thimm wrote:
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'.
.. Except for the fact the kernel patch has "2.6.29.1" right in its name. The kernel doing it like bash would look like:
kernel-2.6.29.tar.bz2 patch-001.bz2
On Wed, Apr 22, 2009 at 12:15:35PM -0500, Callum Lerwick wrote:
On Wed, 2009-04-22 at 08:22 +0300, Axel Thimm wrote:
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'.
.. Except for the fact the kernel patch has "2.6.29.1" right in its name. The kernel doing it like bash would look like:
kernel-2.6.29.tar.bz2 patch-001.bz2
Not sure what you mean, the bash diffs are named like "bash40-017". It does contain the major/minor/patchlevel versions (it lacks conventional delimiters and a sane suffix like ".diff" or ".patch", but that's due to the project's legacy).