Your message dated Mon, 17 Mar 2025 12:37:49 +0000
with message-id <[email protected]>
and subject line Re: Bug#1029957: g-ir-scanner: produces FHS violations by
putting architecture-dependent files in /usr/share
has caused the Debian Bug report #1029957,
regarding g-ir-scanner: produces FHS violations by putting
architecture-dependent files in /usr/share
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1029957: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029957
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: gobject-introspection
Version: 1.74.0-3
Severity: serious
Justification: violates Debian policy section 9.1.1
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.
There is basically three ways to fix this. One option is to change the
location of .gir files to /usr/lib/<triplet>/gir-1.0. Doing so,
fundamentally removes any way of violating FHS due to the additional
remarks in Debian policy section 9.1.1.
The other option is to make gir files truly architecture-independent and
removing any architecture-specific aspects from them.
A third option is to update Debian policy to state exceptions to this
rule given such widespread violation.
I recognize that neither of the first two options is easy to implement.
The former involves a quite elaborate transition and the latter involves
quite a bit work work and likely also breaks some consumers. We also
shipped with this bug in multiple releases, so we certainly want to
ignore it for bookworm. Yet, this does not remove the fact that current
behaviour violates current policy.
Helmut
--- End Message ---
--- Begin Message ---
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.
("Typically" was over-stating this: I am aware of only two GIR XML
modules that vary between architectures, GLib-2.0 and GstAudio-1.0.)
I think we have done all that can be done in gobject-introspection to
solve this without making hundreds of packages FTBFS, so I'm closing
this bug report.
The remaining work that needs to be done is: each package that produces
GIR XML that, unusually, varies between architectures needs to install
it to the secondary, architecture-specific location ${libdir}/gir-1.0
instead of the default ${datadir}/gir-1.0.
For GLib-2.0 this was already done. The libgirepository1.0-dev
metapackage provides backwards-compatibility with bindings generators
that rely on the old location. For GNOME-team-maintained packages I have
been slowly converting libgirepository1.0-dev dependencies into
something more cross-friendly, and I will try to do a mass-bug-filing
and/or a lintian tag deprecating dependencies on libgirepository1.0-dev
after forky development opens, to try to get 99% of the GIR XML
consumers in the archive to be cross-friendly.
For GstAudio-1.0 I've left instructions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023591#28. IMO it's
too late now to be pushing for this to be done before the trixie freeze,
but I will try to remind the maintainers after forky opens that it would
be a good time to make that change. This work is in-scope for #1023591
(aka #1016631) but is out-of-scope for #1029957.
If there are other libraries in the same situation as GstAudio-1.0, then
they should follow a procedure similar to the one I described for
GstAudio-1.0. More details of best-practice are available in
https://salsa.debian.org/gnome-team/gobject-introspection/-/blob/debian/latest/debian/gobject-introspection.README.Debian?ref_type=heads
which is also available on installed systems as
file:///usr/share/doc/gobject-introspection/README.Debian.gz.
smcv
--- End Message ---
