Opened 12 years ago

Last modified 12 years ago

#156 new defect should test for standardized package name

Reported by: warmerdam Owned by: hobu
Priority: major Component: Package
Version: Keywords: liblas
Cc: maphew


I have just done an upgrade on my system with the gui setup, so all installed packages should be up to date.

I did "apt setup" and it seemed to go fine.

Then I did "apt list" and get:

iconv               1.9.1-1
libgeotiff          1.2.5-2
libjpeg             6.b-5
libjpeg-devel       6.b-3
libjpeg12           6.b-3
Traceback (most recent call last):
  File "C:\OSGeo4W\bin\", line 944, in <module>
    __main__.__dict__[command] ()
  File "C:\OSGeo4W\bin\", line 144, in list
    ins = get_installed_version ()
  File "C:\OSGeo4W\bin\", line 436, in get_installed_version
    return split_ball (installed[0][packagename])[1]
  File "C:\OSGeo4W\bin\", line 632, in split_ball
    return ( (1), string_to_version ( (2)))
AttributeError: 'NoneType' object has no attribute 'group'


Any idea what's up?

Change History (4)

comment:1 by maphew, 12 years ago

Keywords: apt added
Status: newassigned

It appears to be specific to the liblas package. The regular expression in def split_ball() which parses out version numbers is coming up empty. A visual scan of grep version: .\path\to\setup.ini shows liblas as the only package version# not ending with -N (hyphen number).

r1155 emits a more informative error in this circumstance, though it might be better to handle this style of version number instead since it appears setup.exe is okay with it. I'm tackling the latter now; my regex is weak so it might take awhile :)

comment:2 by maphew, 12 years ago

Cc:… com added
Component: InstallerPackage
Keywords: liblas added; apt removed
Owner: maphew removed
Status: assignednew
Summary: apt list python should test for standardized package name
Type: defectenhancement

I'm pushing this over to Component:Packaging. According to the cygwin package guide the -N syntax is the package-version, which may also be thought of the as the osgeo4w version, while the 1.1.1 (and variants) syntax is the upstream or vendor version number.

Assuming I've read the history correct, in the case of liblas the package should be "liblas-1.2.1-1.tar.bz2" as this is the first o4w release of the 1.2.1 lidas library.

The fact that setup.exe installed this non-standard package name anyway is probably a bug, and more importantly should test for this too. I've adjusted this issue accordingly; change it back if you disagree :)

I'll document the naming convention in PackagingInstructions.

comment:3 by warmerdam, 12 years ago

Cc: maphew added;… com removed
Owner: set to hobu
Type: enhancementdefect

I concur, liblas should be repacked with a proper version.

It would be nice to check this in the regen script, but I'm not sure if/when that will happen. It's black magic to me.

comment:4 by maphew, 12 years ago

peering through the black haze, in genini I *think* sub getver is incomplete, in that it captures the application version number but not the package version

sub getver {
    my $f = basename($_[0]);
    my @a = ($f =~ /^(.*?)-(\d.*)\.tar/);
    return wantarray ? @a : $a[1];

more like:

sub getver {
    my $f = basename($_[0]);
    my @a = ($f =~ /^(.*?)-(\d.*)-(\d.*)\.tar/);
    return wantarray ? @a : $a[1],$a[2];

explanation: there's a second -(\d.*) to capture the trailing -N. The return wantarray is pseudo code as I've just guessed at the syntax. To be truly useful whatever's calling getver needs to do something if $a[2] is empty.

Note: See TracTickets for help on using tickets.