apt intolerant of filename missing package version number

[maphew]

The recent gdal-filegdb release, #279, reveals apt is pickier than setup.exe when it comes to parsing the version number from the package filename.

B:\> python b:\code\o4w\apt\apt.py new
The following packages are newer than the installed version:

*** Error parsing version numer from "gdal-filegdb-1.9.tar.bz2"

Traceback (most recent call last):
  File "b:\code\o4w\apt\apt.py", line 1113, in <module>
    __main__.__dict__[command] ()
  File "b:\code\o4w\apt\apt.py", line 256, in new
    for packagename in sorted (get_new ()):
  File "b:\code\o4w\apt\apt.py", line 632, in get_new
    new = get_version ()
  File "b:\code\o4w\apt\apt.py", line 684, in get_version
    package['ver'] = split_ball (ball)[1]
  File "b:\code\o4w\apt\apt.py", line 803, in split_ball
    return (m.group (1), string_to_version (m.group (2)))
AttributeError: 'NoneType' object has no attribute 'group'

By spec, the filename is to have program version number followed by a package version number; see PackagingInstructions,

Setup is quite happy to continue without a package version though, so we should follow suit. I looked through Setup source files (package_version.h, .cc) and I think it just assumes a version of 0 if pkg-num missing, e.g. gdal-filegdb-1.9-0.0.tar.bz2 from gdal-filegdb-1.9.tar.bz2.

In apt this would be handled in the (mis-named) def split_ball() parser.

[warmerdam]

I have renamed gdal-filegdb-1.9.tar.bz2 to gdal-filegdb-1.9.0-1.tar.bz2 and regenerated. Hopefully this won't cause too many problems!

Perhaps we should make the regen script(s) stricter about enforcing naming requirements?

[maphew]

Thanks for updating the archive name so existing apt installs can carry on.

It might wise to be stricter on package name convention. Setup.exe is just fine now without the p-ver#, but what would happen with a new version? It might force updating setup.hint manually instead of relying on the automatic "what is current and new" algorithm.

I took the opportunity to understand and document the regex filename-to-version matching, checked in at r1189. I didn't get as far as attempting to add "assume no p-ver# means ver# 0". The parsing is spread across 3 or 4 functions and it really should be in one, with names that mean something. I'm not up to that yet ;-)

[jmalik]

Got this error today experimenting the use of "apt" :

C:\>apt upgrade

Error parsing version numer from "xerces-c-vc9-3.1.1-3-devel.tar.bz2"

Traceback (most recent call last): File "<string>", line 1043, in <module> File "<string>", line 325, in upgrade File "<string>", line 567, in get_new File "<string>", line 617, in get_version File "<string>", line 736, in split_ball AttributeError: 'NoneType' object has no attribute 'group'

[maphew]

(In [1190]) addresses #289: apt to allow trailing characters after package version number. It should allow names like xxx-3.1.1-3-devel in addition to the usual xxx-3.1.1-3. Please test.

apt.split_ball(): extend regex

apt.string_to_version(): using split(s) instead of the over-specific split(s, ' '), which creates a list with empty items (thanks to bruno.42.desthuilliers, ​http://www.gossamer-threads.com/lists/python/python/773794#773794)

[maphew]

@jmalik: you can test by downloading http://trac.osgeo.org/osgeo4w/export/1190/trunk/apt/apt.py, saving locally as %osgeo4w_root%\bin\apt-dev.py, and calling with apt-dev.bat

[jmalik]

@maphew : works for me with 'apt-dev', thanks

I have no updates pending though, so could not test a "real" upgrade. The issue with xerces-c-vc9-3.1.1-3-devel is gone