From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: location@lists.ipfire.org Subject: Re: Upload libloc to Debian Date: Wed, 06 Jul 2022 09:29:17 +0100 Message-ID: <4DB03F40-8299-4448-ADCE-064905D6B831@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4580651485020361441==" List-Id: --===============4580651485020361441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 6 Jul 2022, at 08:41, Jochen Sprickerhof wrote: >=20 > * Michael Tremer [2022-07-05 15:28]: >> The license is part of the database file. That is however not very human-f= rieldy to read. >>=20 >> I added the file to the directory: https://location.ipfire.org/databases/C= OPYING >=20 > Nice, thanks. >=20 >>> Sounds great, I see that the updated puts the file in >>>=20 >>> /var/lib/location/database.db >>>=20 >>> But I don't see where it is used. The libloc-database package would proba= bly 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 t= he package add a symlink to be overwritten by the updater? >>=20 >> 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. >>=20 >> We could also search in a backup location. That would not be a lot of extr= a work. I am just wondering whether that is very intuitive or whether that wo= uld lead to confusion? >=20 > I guess that depends on how well known the location is and if users could m= ess 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 sim= ply make a list and let the module try to open a few unless a specific path h= as been provided. >> Does the build system not support overwriting that file at all? >=20 > In principal you can overwrite the file if you have the rights on the syste= m (for example the updater running as root) but you should not modify (non co= nfiguration) files installed though a package manager. > For one dpkg --verify would complain and also it could produce non determin= istic results if a new package version would overwrite the file again with a = maybe older version. >=20 > I guess the symlink should work, will test it. This is what I expected. However, if =E2=80=94-verify complains, shouldn=E2= =80=99t 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]. >>>>=20 >>>> Oh, I named it that way because that is how Python packages were usually= named in Debian. We can of course absolutely change this. >>>>=20 >>>> Would you be up for sending a patch for this? >>>=20 >>> Sure, as a patch to the list or a pull request on Github? >>=20 >> 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. >=20 > Patch attached. Thank you. That looks good. >>>> That might be a lot easier since you are already an expert with the Debi= an packaging system. We have been fighting a couple of problems that we could= n=E2=80=99t really solve. Maybe you can help us with those, too: https://bugz= illa.ipfire.org/show_bug.cgi?id=3D12468 >>>=20 >>> I was not able to reproduce this, could you send me a log of when this ha= ppens? >>> How do you build the package? With the debian/build.sh? >>=20 >> Yes, we wrote a little helper script to do this. >>=20 >> As mentioned before, I personally have very limited experience with the De= bian build system and so this is what we put together :) Any improvements are= greatly appreciated. >=20 > debian/build.sh uses sbuild so there could be logs from the old runs on you= r system, still. If you could have a look for one with the problem, that woul= d help a lot. Sorry, I forgot to mention that I asked Stefan to upload those log files to t= he ticket. He should let us know on here when he has done so. >>>>> - Similar I would propose to merge the location-importer package into t= he python package (for the library part) and the location package (for the bi= nary). >>>>=20 >>>> We tried to keep the main package as small as possible. The importer par= t is not very large, but it does have a dependency to PostgreSQL. Hence we sp= lit it, because regular users won=E2=80=99t need it. >>>=20 >>> Oh, that does not seem to be modeled in the package. Is the location-impo= rter by normal users of libloc? Otherwise I would propose to add a suggest to= PostgreSQL only. >>=20 >> That is true. We use a database wrapper around psycopg2 which is what shou= ld be added here: >>=20 >> https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dblob;f=3Dsrc/python/lo= cation/database.py;h=3D5d79941515cf830f81d4aff4a1897c4525d99e82;hb=3DHEAD >=20 > 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 i= n your packages as well? Yes, I wouldn=E2=80=99t want any discrepancies here and be as consistent as p= ossible. 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 s= cripts around in our repository. There should only be one set of packages ava= ilable and if that is part of the distribution already, I do not see any reas= on why we should have our own set of packages, too. Best, -Michael >=20 > Cheers Jochen > <0001-Rename-Python-package-to-python3-location.patch> --===============4580651485020361441==--