Bug#1029957: g-ir-scanner: produces FHS violations by putting architecture-dependent files in /usr/share

[Simon McVittie]

Control: severity -1 important

On Sun, 29 Jan 2023 at 16:48:47 +0100, Helmut Grohne wrote:
> g-ir-scanner produces .gir files, which are installed into
> /usr/share/gir-1.0 e.g. by libgirepository1.0-dev. According to Debian
> policy section 9.1.1, such placement must comply with FHS 3.0 and
> according to FHS 3.0 section 4.11.1, data within this directory must be
> architecture-independent. However, the .gir files typically vary with
> the size of various types, the endianess and other aspects. Quite
> obviously, they are not architecture-independent. Thus they violate
> policy.

I don't think this is a serious policy violation, and therefore not RC.
The definitions of bug severities have some necessary weasel words about
"serious" policy violations being RC, implying that not every policy
violation is a serious one.

We follow the FHS because it benefits us, not for the sake of following
the FHS, and I don't believe that the FHS' rationale for distinguishing
between /usr/lib and /usr/share (ability to NFS-mount a single /usr/share
between dissimilar architectures) is either widely done, or well-supported
by dpkg. As a result, I think the main impact of this bug is that a
minority of -dev packages that contain .gir files are not multiarch
co-installable. The examples I'm aware of are #801672/#905715 (really the
same bug) and #1016631/#1023591 (really the same bug).

Also, in pragmatic terms, we've been releasing versions of Debian
that contain gobject-introspection since around 2010 (maybe earlier),
so clearly we are able to do releases despite this bug (and it took
several years for anyone to notice that some of the .gir files contain
architecture variation).

I do intend to (continue to) work on solving this, but pushing for more
FHS-compliant use of /usr/share against upstream objections has not been
my highest priority among several responsibilities inside and outside
Debian (some of which have me as a single point of failure, whereas
gobject-introspection has other maintainers). I don't feel that it would
be responsible behaviour for me to drop everything and prioritize this
bug, and I apologise if you consider that to mean that my dedication to
Policy is insufficient.

If you disagree with my point of view on this sufficiently strongly to
believe this needs to be treated as RC, then you can either convince other
GNOME team members that I'm wrong, or ask the release team to overrule us,
raise the severity, and at the same time, tag it bookworm-ignore (which as
a non-RT member I am not allowed to do), because I don't intend to address
this for bookworm and I don't believe the RT would want the regression
risk of us doing so. But that would put us back into the same practical
situation as a non-RC severity, with extra steps and more people's
limited time spent on it, so I'd really prefer it if you didn't do this.

Thanks,
    smcv