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