Bug#1026231: debian-policy: document droppage of support for legacy locales
On Wed, 21 Dec 2022 at 18:15:11 +0100, Adam Borowski wrote:
> On Mon, Dec 19, 2022 at 07:08:09PM +0000, Simon McVittie wrote:
> > On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > > * The execution environment (usually init system or a container) must
> > > default to UTF-8 encoding unless explicitly configured otherwise.
> >
> > Is this already true? This seems like the sort of thing which should be
> > fixed in at least the major init systems and container managers before it
> > goes into Policy, in the interests of not making those init systems and
> > container managers retroactively buggy.
>
> I'm less knowledgeable about containers, but they appear to work. It might
> be due to copying variables from the host or having template defaults...
There are three major categories of container that I'm aware of:
1. Full-system containers like lxc/lxd run a complete init system like
systemd or sysv-rc for the container (they aim to behave like a
lighter-weight alternative to VMs), so their init system would be
responsible for making this work. This seems non-problematic for your
proposed requirement: if an init system does the right thing on bare
metal or in a VM, it will also do the right thing in lxc containers.
2. Per-service containers like the upstream-recommended use of Docker either
have no init system at all, or a minimal reaper process like tini
(they aim to behave like a heavier-weight alternative to chroots).
chroot managers that have subsequently gained namespace functionality,
like some uses of pbuilder and schroot, also work like this.
I think these are the category that is most likely to have trouble
complying with the requirement you propose, because the container manager
is intentionally "hands-off" (mechanism more than policy), while the
processes run inside the container are not under Debian's control (they
are chosen by whoever wrote the Dockerfile or equivalent, and might come
from either Debian or another distribution).
3. Per-app containers like Flatpak and Snap are not intended to emulate a
whole system, so they are expected to inherit locale settings from the
host system like a non-sandboxed app would. They shouldn't be a problem
here, as long as your proposed requirement is worded in such a way that
it is valid for these container managers to rely on the host system
locale being correct (in other words, if someone using the legacy en_GB
locale reports a bug "flatpak: does not set a UTF-8 locale", I should be
able to close it with "This is not flatpak's job, set your host system
locale to en_GB.UTF-8 instead").
podman and systemd-nspawn can be used as either the first category
(like lxc) or the second (like Docker), depending how they were invoked.
> Anyway, my aim is more to tell packages that they are allowed to misbehave
> when the settings are missing than to hunt misuse scenarios. But, if such
> a scenario is found, with the current Policy there is no recourse, while
> if this rule is added it would be a bug.
Not every bug necessarily needs to be a Policy violation.
> I just tested Windows 11 notepad.exe: it defaults to UTF-8, and when
> saving it allows "ANSI" "UTF-16 LE" "UTF-16 BE" "UTF-8" (default) and
> "UTF-8 with BOM".
Yes, that's the sort of UX that I think needs to be allowed. I would
personally not expose that choice in the UI of an intentionally simple
text editor like Notepad or gnome-text-editor, but I would expect similar
behaviour in an editor with more elaborate programmer-oriented features,
like vim, emacs, gnome-builder or kate.
If iconv(1) or a similar program has an option for "UTF-8 with BOM" then
that also needs to not be accidentally declared to be a Policy violation.
smcv
Reply to: