osgeo4w-regen.sh should test for standardized package name

[warmerdam]

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\apt.py", line 944, in <module>
    __main__.__dict__[command] ()
  File "C:\OSGeo4W\bin\apt.py", line 144, in list
    ins = get_installed_version ()
  File "C:\OSGeo4W\bin\apt.py", line 436, in get_installed_version
    return split_ball (installed[0][packagename])[1]
  File "C:\OSGeo4W\bin\apt.py", line 632, in split_ball
    return (m.group (1), string_to_version (m.group (2)))
AttributeError: 'NoneType' object has no attribute 'group'

C:\OSGeo4W\bin>

Any idea what's up?

[maphew]

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 :)

[maphew]

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 osgeo4w-regen.sh 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.

[warmerdam]

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.

[maphew]

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.