Clarify core data model, we're in a data muddle

[maphew]

When working on better information messages from apt info command I realized I've made a muddle:

4b9190f The main data tables need clear separation, "package names and version available on server" and "what is actually locally installed". The old functions actually maintained this better before I started messing with them. (In my defense, they were horribly opaque tho'.)

For instance I grew the idea that apt ball reconstructed the version name from the currently available archive filename on the server. Yes, get_ball() constructs from the filename, but not from the filename in setup.ini, it's actually from the name in installed.db -- a crucial difference!

TODO: rescue good parts of old functions, clearly separate local/server info, dump overlapping dict records.

So something like

SETUP = parse_setup_ini()
INSTALLED = parse_installed_db()

I want to think carefully about the names though. We'll be using them frequently. They should make intuitive sense when read, while being short enough to cause no typing strain and keep our code phrases short and fast to read.

• ALLCAPS is out; no shouting.
• setup_ini is being used (but could be moved, with some effort)
• setup_d, installed_d ?
• sini_d, inst_d ?
• ini_d, inst_d ?
• S, I ? (is this still shouting?)
• ...?

A couple of spelled out phrases:

p = packagename

server_ver = sini_d[p]['version']
local_ver  = inst_d[p]['version']
server_ver = S[p]['version']
local_ver  = I[p]['version']

if sini_d[p]['version'] > inst_d[p]['version']:
    do_upgrade(p)

if S[p]['version'] > I[p]['version']:
    do_upgrade(p)

[amr66]

I got a problem to understand how to distinguish between dists ['curr', 'prev', 'test'] if a package is installed. Is it always in responsibility of the user? Say, apt upgrade is used with a package in prev and another in curr? I'm asking, because in my OO-Try i didn't know where to put the information from setup.ini and installed.db if there are several dists. I think we should store the dist with the installed package, but we want to be compatible with osgeo4w-setup.exe, right?
May be we could change package names according to the dist? E.g. gdal and gdal-prev?

[jef-n]

you don't need to distinguish in installed.db - a package is just installed in one version - it doesn't matter if it was curr, prev or test.
In osgeo4w-setup you get upgrades to test versions if you check Exp(erimental).
On debian you can specify distributions via -t (eg. -t experimental or -t wheezy-backports) or specify explicit available versions by apt-get install package=$versionno).

[amr66]

Oh, didn't know these possibility in apt-get, I should interview our system administrator :-)
And yes, I came to the same conclusion with 'curr', 'test' and 'prev', was just a little confused. In apt this is missing, because we only deal with 'curr' right now?

[amr66]

Oh, and as noted else where: Comparing version strings fails by simple comparsion with logical less than (<), 1.11.1 < 1.9.1 gives true.
http://stackoverflow.com/questions/1714027/version-number-comparison

[maphew]

Thanks for the clarification Jurgen!

Apt has some (inherited) code stubs for dealing with prev, curr, test. I've not taken time to dig in and see if they can be made to work; curr and --ini=.... has been good enough for me. I would like to achieve/maintain functional parity with -setup.exe though, so handling at least test would be good.

Created #36 for version handling fixing, thanks Andreas.

[amr66]

I did a small installation with osgeo4w-setup.exe and there was no setup.ini in /etc/setup. I think it changed with x64-packages. setup.ini is now under ./cryptic-download-dir/x86/ and this is not mandotory OSGEO4W_ROOT/dev/..., like I assumed for my portable installation.
So we always have to read setup.rc and last_cache entry, which i think apt does?

[maphew]

I didn't know the location of extracted setup.ini had changed. Thanks for the heads up.

Use of setup.rc is not complete, see #18.

[amr66]

I'am returning th the clarify-discussion:
at least we have

• a dict for setup/config, containing values from setup.rc,
• a dict with available packages from the server, retrieved from setup.ini
• a dict with installed packages, containing data from installed.db
  Any aditional information that could be generated should clearly derive or be added to these dictionaries. So as I would like to avoid to much global variables, we can think of additional keys inside of three global disctionary. We wouldn't have "last_mirror", but "global_dict_setup['last_mirror']". I did something like that in my object oriented code, expanding the data with those global variables for pathes, dists etc. With xy_get_info_abc() we could ask for values from theses dicts.

[maphew]

Going to push for an exe package release before seeing this through, and putting the target for "just 3 globals" to 2nd release from now, to give some breathing room for it to be done properly.