I did a "yum upgrade" and was offered:
qbittorrent x86_64 1:2.2.8-2.fc13
even though I currently have:
$ rpm -q qbittorrent qbittorrent-2.2.9-1.fc13.x86_64
(Note the version numbers)
I said 'N' because it seems at least counter-intuitive. Is there any way to check that the proposed upgrade really supersedes the installed version, or should I complain to the qbt maintainer?
poc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2010 10:31 AM, Patrick O'Callaghan wrote:
I did a "yum upgrade" and was offered:
qbittorrent x86_64 1:2.2.8-2.fc13
even though I currently have:
$ rpm -q qbittorrent qbittorrent-2.2.9-1.fc13.x86_64
(Note the version numbers)
I said 'N' because it seems at least counter-intuitive. Is there any way to check that the proposed upgrade really supersedes the installed version, or should I complain to the qbt maintainer?
poc
You see the 1: before the version number in the version you were offered? That means that an epoch bump occurred (this is used primarily to deal with when a package has changed version number schemes and the new version numbers are lower than the old ones)
It is also done in very rare occasions to force a downgrade from a known-bad version of a piece of software.
- From the update description: * Tue Jul 20 2010 Leigh Scott leigh123linux@googlemail.com - 2.2.8-2 - add epoch and revert version to 2.2.8 as the newer versions violate the bundled libs guidelines
The newer version 2.2.9 was in violation of Fedora policies (specifically, bundled libs can have unfixed security vulnerabilities), so the epoch was bumped to force a downgrade.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Patrick O'Callaghan wrote, at 07/21/2010 11:31 PM +9:00:
I did a "yum upgrade" and was offered:
qbittorrent x86_64 1:2.2.8-2.fc13
even though I currently have:
$ rpm -q qbittorrent qbittorrent-2.2.9-1.fc13.x86_64
(Note the version numbers)
I said 'N' because it seems at least counter-intuitive. Is there any way to check that the proposed upgrade really supersedes the installed version, or should I complain to the qbt maintainer?
poc
You can see the new qbittorrent has *1:*2.2.8-2.fc13 EVR (Epoch-Version-Release). The part "1:" is rpm's "Epoch" which has higher priority than Version, so rpm regards that "1:2.2.8" is higher than "2.2.9".
Usually Epoch is introduced when the maintainer wants to intentionally downgrade version like this (because it was found that higher version had some issue or so), or when the upstream uses some strange versioning strategy.
Regards, Mamoru
On Wed, 2010-07-21 at 10:43 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2010 10:31 AM, Patrick O'Callaghan wrote:
I did a "yum upgrade" and was offered:
qbittorrent x86_64 1:2.2.8-2.fc13
even though I currently have:
$ rpm -q qbittorrent qbittorrent-2.2.9-1.fc13.x86_64
(Note the version numbers)
I said 'N' because it seems at least counter-intuitive. Is there any way to check that the proposed upgrade really supersedes the installed version, or should I complain to the qbt maintainer?
poc
You see the 1: before the version number in the version you were offered? That means that an epoch bump occurred (this is used primarily to deal with when a package has changed version number schemes and the new version numbers are lower than the old ones)
It is also done in very rare occasions to force a downgrade from a known-bad version of a piece of software.
- From the update description: * Tue Jul 20 2010 Leigh Scott leigh123linux@googlemail.com -
2.2.8-2 - add epoch and revert version to 2.2.8 as the newer versions violate the bundled libs guidelines
The newer version 2.2.9 was in violation of Fedora policies (specifically, bundled libs can have unfixed security vulnerabilities), so the epoch was bumped to force a downgrade.
Thanks Stephen (and Mamoru). I did notice the epoch number but "rpm -qi" on the current version (2.2.9) doesn't show the epoch so I wasn't sure.
poc
On 07/21/2010 07:31 AM, Patrick O'Callaghan wrote:
I did a "yum upgrade" and was offered:
qbittorrent x86_64 1:2.2.8-2.fc13
even though I currently have:
$ rpm -q qbittorrent qbittorrent-2.2.9-1.fc13.x86_64
(Note the version numbers)
I said 'N' because it seems at least counter-intuitive. Is there any way to check that the proposed upgrade really supersedes the installed version, or should I complain to the qbt maintainer?
poc
It might be coming from non fedora repo you have installed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2010 11:14 AM, Patrick O'Callaghan wrote:
Thanks Stephen (and Mamoru). I did notice the epoch number but "rpm -qi" on the current version (2.2.9) doesn't show the epoch so I wasn't sure.
poc
No epoch is equivalent to epoch zero. That's why it wasn't displayed.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen Gallagher wrote, at 07/22/2010 03:21 AM +9:00:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2010 11:14 AM, Patrick O'Callaghan wrote:
Thanks Stephen (and Mamoru). I did notice the epoch number but "rpm -qi" on the current version (2.2.9) doesn't show the epoch so I wasn't sure.
poc
No epoch is equivalent to epoch zero. That's why it wasn't displayed.
To be clear: By default "$ rpm -q" ($ rpm -qi) does not show epoch information even if the rpm actually has epoch. e.g.
[tasaka1@localhost ~]$ rpm -q xscreensaver-base xscreensaver-base-5.11-7.fc14.respin1.i686 [tasaka1@localhost ~]$ rpm -q --qf '%{name}-%{evr}.%{arch}\n' xscreensaver-base xscreensaver-base-1:5.11-7.fc14.respin1.i686 [tasaka1@localhost ~]$ env LANG=C yum info xscreensaver-base Installed Packages Name : xscreensaver-base Arch : i686 Epoch : 1 Version : 5.11 Release : 7.fc14.respin1 Size : 1.3 M Repo : installed .... ....
Regards, Mamoru
On Thu, 2010-07-22 at 03:49 +0900, Mamoru Tasaka wrote:
No epoch is equivalent to epoch zero. That's why it wasn't
displayed.
To be clear: By default "$ rpm -q" ($ rpm -qi) does not show epoch information even if the rpm actually has epoch.
That might be worth revising. The rpm queryformat expressions are not well documented on the man page (you have to know what the various tag headers are called for one thing, and it's not clear where to discover that short of reading the RPM book or the source).
poc
On 21 July 2010 21:13, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Thu, 2010-07-22 at 03:49 +0900, Mamoru Tasaka wrote:
No epoch is equivalent to epoch zero. That's why it wasn't
displayed.
To be clear: By default "$ rpm -q" ($ rpm -qi) does not show epoch information even if the rpm actually has epoch.
That might be worth revising. The rpm queryformat expressions are not well documented on the man page (you have to know what the various tag headers are called for one thing, and it's not clear where to discover that short of reading the RPM book or the source).
The last paragraph of the section of `man rpm` dealing with --queryformat says the following:
For example, to print only the names of the packages queried, you could use %{NAME} as the format string. To print the packages name and dis- tribution information in two columns, you could use %-30{NAME}%{DISTRI- BUTION}. rpm will print a list of all of the tags it knows about when it is invoked with the --querytags argument.
You can therefore list all the tags as follows:
[sam@samlap ~ ]$ rpm --querytags ARCH ARCHIVESIZE BASENAMES BUGURL BUILDARCHS BUILDHOST BUILDTIME <snip>
However it's left as an exercise for the reader to discover what the non-obvious query tags actually mean.
-- Sam
On Wed, 2010-07-21 at 21:32 +0100, Sam Sharpe wrote: [...]
The last paragraph of the section of `man rpm` dealing with --queryformat says the following:
For example, to print only the names of the packages queried, you could use %{NAME} as the format string. To print the packages name and dis- tribution information in two columns, you could use %-30{NAME}%{DISTRI- BUTION}. rpm will print a list of all of the tags it knows about when it is invoked with the --querytags argument.You can therefore list all the tags as follows:
[sam@samlap ~ ]$ rpm --querytags ARCH ARCHIVESIZE BASENAMES BUGURL BUILDARCHS BUILDHOST BUILDTIME
<snip>
However it's left as an exercise for the reader to discover what the non-obvious query tags actually mean.
Quite so. Such names as 'N', 'E', 'O' etc. are not what one would call self-evident (those specific ones mean Name, Epoch and "something I can't easily discover by experiment but mostly gives the result (none)".)
poc
-
JD -
Mamoru Tasaka -
Patrick O'Callaghan -
Sam Sharpe -
Stephen Gallagher