[opensuse] generally accepted that rpm version numbers are not guaranteed to collate properly?
Had 2 versions of a package where a script I had tried to delete the older package when the newer one was downloaded to replace it. But in this case, comparing Printrun-2.0.0~rc5.1522069560.e0ee40a-2.5.x86_64.rpm against Printrun-20170720~pre.1494969671.f54b6f9-1.1.x86_64.rpm The 2.0 version is the latest, but the rpm-ver compare seems to look at numeric v. non-numeric fields and ends up comparing '2' to 20170720 -- and comes up with 2 < 20170720, so '2' is older. Seems like there really is no way to compare rpm versions that are like this, with the only result being that the distro-downloader needs delete older version when it installs a new version, which can be a pain if there was some change between the two that you might want to compare or back out. Admittedly, as a % of packages downloaded, it is a VERY small number where that happens, often 0. But it seems like more often, some new version of something breaks something that used to work, so it seems prudent to keep those things around. Probably little can be done about this, just a matter of adapting to a bogus environment. Sigh. -linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
29 дек. 2019 г., в 13:45, L A Walsh <suse@tlinx.org> написал(а):
Had 2 versions of a package where a script I had tried to delete the older package when the newer one was downloaded to replace it.
But in this case, comparing Printrun-2.0.0~rc5.1522069560.e0ee40a-2.5.x86_64.rpm against Printrun-20170720~pre.1494969671.f54b6f9-1.1.x86_64.rpm
The 2.0 version is the latest, but the rpm-ver compare seems to look at numeric v. non-numeric fields and ends up comparing '2' to 20170720 -- and comes up with 2 < 20170720, so '2' is older.
Seems like there really is no way to compare rpm versions that are like this, with the only result being that the distro-downloader needs delete older version when it installs a new version, which can be a pain if there was some change between the two that you might want to compare or back out. Admittedly, as a % of packages downloaded, it is a VERY small number where that happens, often 0.
But it seems like more often, some new version of something breaks something that used to work, so it seems prudent to keep those things around.
Probably little can be done about this,
That vid exactly what RPM epoch is for. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019/12/29 08:48, Andrei Borzenkov wrote:
That vid exactly what RPM epoch is for.
--- I have yet to see any value for 'epoch' other than '0'. Maybe it hasn't been implemented yet? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019/12/29 08:48, Andrei Borzenkov wrote:
13:45, L A Walsh :
Had 2 versions of a package where a script I had tried to delete the older package when the newer one was downloaded to replace it.
But in this case, comparing Printrun-2.0.0~rc5.1522069560.e0ee40a-2.5.x86_64.rpm against Printrun-20170720~pre.1494969671.f54b6f9-1.1.x86_64.rpm
The 2.0 version is the latest, but the rpm-ver compare seems to look at numeric v. non-numeric fields and ends up comparing '2' to 20170720 -- and comes up with 2 < 20170720, so '2' is older.
That is exactly what RPM epoch is for.
---- Actually, is this something that should be set in those files by opensuse? In this case, I think both were from tumbleweed. How would packaging people know to bump the epoch number? I.e. if the version scheme has changed for a given package, then should the packager bump that? Or is it something that would be done by a script comparing new and old versions (though where they'd know what old versions to compare against, I dunno), and bumping epoch if the newer package sorts as an older version? I sorta wondered what epoch was for but since I only ever saw it as zero, I didn't give it alot of thought. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
30.12.2019 10:32, L A Walsh пишет:
On 2019/12/29 08:48, Andrei Borzenkov wrote:
13:45, L A Walsh :
Had 2 versions of a package where a script I had tried to delete the older package when the newer one was downloaded to replace it.
But in this case, comparing Printrun-2.0.0~rc5.1522069560.e0ee40a-2.5.x86_64.rpm against Printrun-20170720~pre.1494969671.f54b6f9-1.1.x86_64.rpm
The 2.0 version is the latest, but the rpm-ver compare seems to look at numeric v. non-numeric fields and ends up comparing '2' to 20170720 -- and comes up with 2 < 20170720, so '2' is older.
That is exactly what RPM epoch is for.
---- Actually, is this something that should be set in those files by opensuse? In this case, I think both were from tumbleweed. How would packaging people know to bump the epoch number? I.e. if the version scheme has changed for a given package, then should the packager bump that?
Yes. That is how it worked e.g. in Mandrake. SUSE traditionally relied on "zypper dup" magic for this.
Or is it something that would be done by a script comparing new and old versions (though where they'd know what old versions to compare against, I dunno), and bumping epoch if the newer package sorts as an older version?
Any implementation that compares RPM package versions must take in account epoch. When to bump epoch is packager decision.
I sorta wondered what epoch was for but since I only ever saw it as zero, I didn't give it alot of thought.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
L A Walsh