id summary reporter owner description type status priority component version resolution keywords cc 289 apt intolerant of filename missing package version number maphew 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 __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, [[Image(http://trac.osgeo.org/osgeo4w/raw-attachment/wiki/PackagingInstructions/package-name.png)]] 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. " defect closed major Package fixed pkg-apt rburhum