Clarify core data model, we're in a data muddle about apt HOT 9 OPEN

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?

from apt.

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

from apt.

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?

from apt.

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

from apt.

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.

from apt.

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?

from apt.

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.

from apt.

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.

from apt.

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.

from apt.