Hello,
On 6 Jul 2022, at 08:41, Jochen Sprickerhof libloc@jochen.sprickerhof.de wrote:
- Michael Tremer michael.tremer@ipfire.org [2022-07-05 15:28]:
The license is part of the database file. That is however not very human-frieldy to read.
I added the file to the directory: https://location.ipfire.org/databases/COPYING
Nice, thanks.
Sounds great, I see that the updated puts the file in
/var/lib/location/database.db
But I don't see where it is used. The libloc-database package would probably install to /usr/share/libloc-database/database.db. Would it be easier if libloc uses that path as a backup if the one in /var is not there or should the package add a symlink to be overwritten by the updater?
The updater would overwrite that symlink since it downloads the file to a temporary location, verifies it with the key, and then replaces the old file. So that would work.
We could also search in a backup location. That would not be a lot of extra work. I am just wondering whether that is very intuitive or whether that would lead to confusion?
I guess that depends on how well known the location is and if users could mess with the file such that it would be good to have some program logic with a fall back.
It slightly varies where distributions put those database files. We could simply make a list and let the module try to open a few unless a specific path has been provided.
Does the build system not support overwriting that file at all?
In principal you can overwrite the file if you have the rights on the system (for example the updater running as root) but you should not modify (non configuration) files installed though a package manager. For one dpkg --verify would complain and also it could produce non deterministic results if a new package version would overwrite the file again with a maybe older version.
I guess the symlink should work, will test it.
This is what I expected. However, if —-verify complains, shouldn’t it complain about the symlink, too?
- According to the Debian Python policy the Python package needs to be renamed to python3-location. It would simplify the transition if you could do the same in your package repo and add a transition package [3].
Oh, I named it that way because that is how Python packages were usually named in Debian. We can of course absolutely change this.
Would you be up for sending a patch for this?
Sure, as a patch to the list or a pull request on Github?
Please use this list only. We have our tools integrated to it, and GitHub does not allow us to host the database on there since it is too large - so we try to keep the home of the project on our own infrastructure.
Patch attached.
Thank you. That looks good.
That might be a lot easier since you are already an expert with the Debian packaging system. We have been fighting a couple of problems that we couldn’t really solve. Maybe you can help us with those, too: https://bugzilla.ipfire.org/show_bug.cgi?id=12468
I was not able to reproduce this, could you send me a log of when this happens? How do you build the package? With the debian/build.sh?
Yes, we wrote a little helper script to do this.
As mentioned before, I personally have very limited experience with the Debian build system and so this is what we put together :) Any improvements are greatly appreciated.
debian/build.sh uses sbuild so there could be logs from the old runs on your system, still. If you could have a look for one with the problem, that would help a lot.
Sorry, I forgot to mention that I asked Stefan to upload those log files to the ticket. He should let us know on here when he has done so.
- Similar I would propose to merge the location-importer package into the python package (for the library part) and the location package (for the binary).
We tried to keep the main package as small as possible. The importer part is not very large, but it does have a dependency to PostgreSQL. Hence we split it, because regular users won’t need it.
Oh, that does not seem to be modeled in the package. Is the location-importer by normal users of libloc? Otherwise I would propose to add a suggest to PostgreSQL only.
That is true. We use a database wrapper around psycopg2 which is what should be added here:
https://git.ipfire.org/?p=location/libloc.git;a=blob;f=src/python/location/d...
Ah, that's much easier, you can add python3-psycopg2 to the Depends: field of the location-importer package in debian/control.
For Debian I would still propose to merge the packages, should we do that in your packages as well?
Yes, I wouldn’t want any discrepancies here and be as consistent as possible.
So, would you be up for submitting a patch for this as well?
Ultimately, I am not even sure if there is any point in keeping those build scripts around in our repository. There should only be one set of packages available and if that is part of the distribution already, I do not see any reason why we should have our own set of packages, too.
Best, -Michael
Cheers Jochen <0001-Rename-Python-package-to-python3-location.patch>