Hi Aurelien!
On 26.07.24 13:11, Aurelien Jarno wrote:
Hi,
On 2024-07-25 00:34, Lee Garrett wrote:
So when /etc/locale.gen exists, this file is read, and then the settings in
the debconf database overwritten by those value. So once debconf is
installed, there's no programmatic way via debconf to change the locale. A
workaround is template the files /etc/locale.gen and /etc/locale.conf and
then run dpkg-reconfigure locales.
Yes, this works exactly as expected. debconf can be used to preconfigure
the package before it gets installed. But *debconf is not a registry*. The
way to change the configuration is by editing the files.
This is very clear in the debconf manual:
"You can also use debconf in other, standalone programs. The issue to watch out
for here is that debconf is not intended to be, and must not be used as a
registry. This is unix after all, and programs are configured by files in /etc,
not by some nebulous debconf database (that is only a cache anyway and might
get blown away). So think long and hard before using debconf in a standalone
program."
https://manpages.debian.org/unstable/debconf-doc/debconf-devel.7.en.html
Indeed. This doesn't seem to be widely spread knowledge, though. A google search
[0] mostly reveals hits from 20 years ago (and, ironically, now this bug report).
Fine by me then. However, from the user perspective, this is inconsistent
behaviour that depends on the order of things.
Assume the following possible steps a user can take:
A) install locales
B) set debconf values
C) run `dpkg-reconfigure --frontend=noninteractive locales`
D) run `dpkg-reconfigure locales` interactively
ABD -> debconf is authoritative
ABC -> config files are authoritative
BAC -> debconf is authoritative
Given that a lot more installations nowadays are programmatically provisioned
and also administered through config management, I believe this is a more
important issue than 20 years ago.
This however seems counterintuitive to me, as practically all other packages
using debconf have the debconf database as authoritative data from which the
config is written (e.g. apt-cacher-ng, ca-certificates, console-setup,
iproute2, grub-efi-amd64, grub-pc, postfix, tzdata, wireshark-common, to
name a few).
Then those packages are buggy, please report bugs. And I really doubt
about the behaviour you describe, for at least tzdata.
Indeed, you are right:
# debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone
tzdata tzdata/Zones/Europe select Berlin
Europe/Berlin
# cat | debconf-set-selections
tzdata tzdata/Zones/Europe select Bratislava
# debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone
tzdata tzdata/Zones/Europe select Bratislava
Europe/Berlin
# dpkg-reconfigure --frontend=noninteractive tzdata
Current default time zone: 'Europe/Berlin'
Local time is now: Fri Jul 26 16:41:02 CEST 2024.
Universal Time is now: Fri Jul 26 14:41:02 UTC 2024.
# debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone
tzdata tzdata/Zones/Europe select Berlin
Europe/Berlin
Neither /etc/locale.gen, nor /etc/locale.conf are marked as conffiles, so
they shouldn't edited by users, and neither be preserved, nor authoritative
on the matter. As such, I'm raising the bug severity.
They are not conffiles, because there are not mandatory and thus not
shipped by the package. But it's something we can change.
True. I think that was what threw me off. Since they're not conffiles, I assume
they should not be edited. Especially since they are overwritten when debconf is
run interactively (but not when run non-interactively).
In any case, as you raised the bug to serious, could you please tell me
which section of the Debian policy is violated?
I guess 10.7.3. would be the closest match.
"These scripts must be idempotent (i.e., must work correctly if dpkg needs to
re-run them due to errors during installation or removal), must cope with all
the variety of ways dpkg can call maintainer scripts, must not overwrite or
otherwise mangle the user’s configuration without asking, must not ask
unnecessary questions (particularly during upgrades), and must otherwise be good
citizens."
In this case it's not idempotent (in the broader sense), depending on if debconf
are set before or after package installation. But this seems like a broader
issue that might need to be discussed on debian-devel. As such I'm downgrading
the bug again to unblock transitions to testing.
I think shipping locale.gen and locale.conf as conffiles would still be nice to
have. Shall I file a seperate bug for that?
I propose to remove the shown code lines from locales.config. This would
make any debconf selections authoritative again.
As said above this is wrong.
Agreed.
A compromise would be to add another debconf option that decides on which
side is authoritative (either config file, or debconf), but IMHO that adds
complexity without much benefit.
I agree with you it should not be done.
Agreed.
Regards
Aurelien
Best regards,
Lee
[0] https://www.google.com/search?q=%22debconf%20is%20not%20a%20registry%22
