The `location` binary package in our Debian repository ships `/var/lib/location/database.db` (42,809,631 bytes, created 2024-09-28) and `/var/lib/location/signing-key.pem` (via `debian/location.install`). Upgrading `location` from 0.9.18-3 to 0.9.19-1.build-45.1 on a host that already had a current database (created 2026-10-21 04:40 UTC, downloaded by `location update`) replaced it with the 2024 file. The service that uses it (PowerDNS with lua-location) then served 2024 data until `location update` was run by hand. The SOA serial, which comes from `db:created_at()`, went from 1792557613 to 1727498505. Version: libloc 0.9.19-1.build-45.1 (https://repo.ipfire.org/debian/libloc/master, trixie) Expected behaviour: Upgrading `location` must not touch a database that `location update` has downloaded. Debian's own `location` package does not ship anything in /var/lib/location: its postinst only symlinks /var/lib/location/database.db to /usr/share/libloc-location/location.db (libloc-database). The postinst of our package still contains that `ln -s ... || true`, which now silently fails because a regular file has been installed there. Suggested fix: Remove `var/lib/location/database.db` and `var/lib/location/signing-key.pem` from `debian/location.install`. The database and the key are only needed by the tests (data/database.db), so they can stay in the source tree. If a baseline database is wanted, use the symlink to libloc-database like Debian does. Impact: Every host that installs or upgrades `location` from our repository. Hosts that use libloc-database through the symlink would get the symlink replaced by this old file. Workaround: run `location update` after the upgrade. PowerDNS picks the new file up without a restart, since libloc 0.9.19 reloads the database every 300 seconds.
Correction to the suggested fix in the description: only /var/lib/location/database.db should be removed from debian/location.install. /var/lib/location/signing-key.pem has to stay in the package, because `location update` needs it as the public key to verify a downloaded database (default --public-key is @databasedir@/signing-key.pem, see src/scripts/location.in and downloader.py, _check_database()). Without the key, `location update` fails after the download with: Downloaded new database from Wed, 21 Oct 2026 04:40:13 GMT Could not download a new database because opening the missing public key raises FileNotFoundError, which is reported as a failed download. We saw this on a host where /var/lib/location/database.db and signing-key.pem were both missing after the upgrade to 0.9.19-1.build-45.1 (dpkg -V location reported both as missing). I could not find out what removed them there.
https://git.ipfire.org/?p=location/libloc.git;a=commit;h=d97e70ed344bfb17dcc3e5f88fea941c820791bd Author: Michael Tremer <michael.tremer@ipfire.org> debian: Don't ship a database The location package installed the default database into /var/lib/location, which is where "location update" stores the database it has downloaded. Upgrading the package therefore replaced a current database with the old one that is shipped with the source tree, and the programs that use it carried on with outdated data until the next update. Debian's own package ships nothing there either, and the postinst already links the database of libloc-database to that path when it can. The Makefile still installs the database, because other distributions package it that way. debhelper fails on files that are installed but not packaged (since compat 13), so list the database in debian/not-installed. The public key stays, since "location update" needs it to verify the databases that it downloads. Fixes: #14573 - debian: location package ships /var/lib/location/database.db, which overwrites the current database on upgrade Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fixed in libloc master: d97e70e (debian: Don't ship a database). The package no longer installs /var/lib/location/database.db, and signing-key.pem stays. The first upgrade from a package that ships the database will remove that file, because dpkg removes files that the new version does not own. The Debian package has not been built with this change yet.
This has been fixed in libloc 0.9.20, which has just been tagged. Closing this as fixed.