Bug 621381 - yumBackend.py get_distro_upgrades version parsing
yumBackend.py get_distro_upgrades version parsing
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-04 17:55 EDT by Paul B Schroeder
Modified: 2010-08-31 16:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-31 16:13:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
more robust distro version handling in yumBackend.py (1.50 KB, application/octet-stream)
2010-08-04 17:55 EDT, Paul B Schroeder
no flags Details

  None (edit)
Description Paul B Schroeder 2010-08-04 17:55:50 EDT
Created attachment 436682 [details]
more robust distro version handling in yumBackend.py

Description of problem:
I'm working on a F12 based distro, the first version of which I versioned as "1.2".  I recently did an update and upped my release package to "1.2.1".  This causes issues with the yum backend as "1.2.1" isn't a valid float.  The version comparison code should probably be a little more robust.

Traceback (most recent call last):
File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2383, in get_distro_upgrades
present_version = float(self.yumbase.conf.yumvar['releasever'])
ValueError: invalid literal for float(): 1.2.1 

Version-Release number of selected component (if applicable):
PackageKit-0.5.7-2.fc12
PackageKit-0.6.6-1.fc13

How reproducible:
Create a "fedora-release" or whatever release package with more than one point number in it (i.e. x.y.z) and see the traceback.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Attaching patch which addresses the issue...  The patch is against PackageKit-0.5.7-2.fc12, but I've verified that it applies to PackageKit-0.6.6-1.fc13 just fine with an offset..
Comment 1 Richard Hughes 2010-08-31 05:59:53 EDT
I'm pretty sure releasever is meant to be a floating point number -- I've seen quite a bit of code in preupgrade that treats it as a floating point. Can't you just have 1.21 as a version id?
Comment 2 Paul B Schroeder 2010-08-31 12:08:33 EDT
It would be a pain to use 1.21 as a version id at this point.  We have a build/release process in place that already expects major.minor.patch.

I haven't looked at preupgrade, but I see no reason why fixing this here would affect that.  If we start using preupgrade in some way, I'm sure I'd run into this again and would be happy to provide a patch for it.

In the end, it seems to me that treating versions as floating points is flawed and should be fixed.
Comment 3 Richard Hughes 2010-08-31 15:24:00 EDT
(In reply to comment #2)
> It would be a pain to use 1.21 as a version id at this point.  We have a
> build/release process in place that already expects major.minor.patch.

A Fedora release process?

> I haven't looked at preupgrade, but I see no reason why fixing this here would
> affect that.  If we start using preupgrade in some way, I'm sure I'd run into
> this again and would be happy to provide a patch for it.

Well, preupgrade uses > and < to determine the relative age of the releases.

> In the end, it seems to me that treating versions as floating points is flawed
> and should be fixed.

Erm, that's not my thoughts at all, sorry. In my opinion having a distro version (that's normally an integer, and sometimes a float) as a string "1.2.1" doesn't make much sense.
Comment 4 Paul B Schroeder 2010-08-31 15:58:42 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > It would be a pain to use 1.21 as a version id at this point.  We have a
> > build/release process in place that already expects major.minor.patch.
> 
> A Fedora release process?
Not exactly, no..

> 
> > I haven't looked at preupgrade, but I see no reason why fixing this here would
> > affect that.  If we start using preupgrade in some way, I'm sure I'd run into
> > this again and would be happy to provide a patch for it.
> 
> Well, preupgrade uses > and < to determine the relative age of the releases.
So does the patch I provided (please take a look).  It breaks down the version string into a list of integers and then compares them.  The patch is completely backwards compatible with folks who still want to use simple integer or float (major.minor) for their versioning.  This patch doesn't break preupgrade.  It just adds more version flexibility to yumBackend.py.

> 
> > In the end, it seems to me that treating versions as floating points is flawed
> > and should be fixed.
> 
> Erm, that's not my thoughts at all, sorry. In my opinion having a distro
> version (that's normally an integer, and sometimes a float) as a string "1.2.1"
> doesn't make much sense.
It makes complete sense.  There are a lot of examples of software releases which use more than just a simple integer or a float.  PackageKit itself uses release numbers that don't fit that scheme (e.g. PackageKit 0.6.6 is on my machine now).

As I mentioned above, this doesn't break anything, it just adds flexibility for those of us who wish to use more complex versioning.
Comment 5 Richard Hughes 2010-08-31 16:13:00 EDT
(In reply to comment #4)
> > Well, preupgrade uses > and < to determine the relative age of the releases.
> So does the patch I provided (please take a look).

I did, and it's way more complex than just parsing the float. It's going to be even trickier to do the same thing for preupgrade that would need to do a rpmcmpver-type method for the release string. You can't just compare the array elements as that won't work when comparing variable length arrays.

> This patch doesn't break preupgrade.

No, my point is that a version of 0.1.2 /would/ break preupgrade.

> It just adds more version flexibility to yumBackend.py.

Flexability == complexity, and more things that need to be supported and debugged. You have to appreciate that I have to do a cost-benefit reasoning for added lines of code verses maintainance cost.

In this case, I think you either need to patch PK and preupgrade in your forked F12 distro, or to change your version number to 1.21 or even 1.3.

Note You need to log in before you can comment on or make changes to this bug.