Here is an attempt at a more comprehensive answer to your questions about
correct handling of Cinnamon's private typelibs and private GIR XML.
The first thing I should say is that the GObject-Introspection mini-policy
(file:///usr/share/doc/gobject-introspection/policy.txt.gz) was written for
the common case of public libraries, typelibs and GIR XML, for example GTK
or libsoup:
- libraries in /usr/lib/MULTIARCH/
- typelibs in /usr/lib/MULTIARCH/girepository-1.0
- GIR XML in /usr/share/gir-1.0 or /usr/lib/MULTIARCH/gir-1.0
Tools like dh_girepository and Lintian are also set up for that common
case, and it's entirely possible that they are not always doing the right
thing for private libraries, typelibs and GIR XML. Not many packages use
private typelibs or GIR XML, and it's probably mostly only GNOME and
Cinnamon that do this, so it's up to the GNOME and Cinnamon maintainers to
figure out how private libraries with typelibs and GIR XML ought to work.
I am not a Cinnamon user or developer, but if I understand the Cinnamon
packages directly, src:cinnamon contains private libraries, typelibs and
GIR XML, similar to src:gnome-shell.
When installing private libraries that are only intended to be used
within a group of closely cooperating packages, you don't necessarily
have to follow all of the same policies that you would need to follow
for a public library like GTK or libsoup, as long as the setup that
ends up in the packages you have built still works correctly within your
closed ecosystem.
For instance, in GNOME we have some private libraries built by src:mutter
and src:gnome-shell, which are used by GNOME Shell, Budgie and GNOME
Shell extensions, but should not be accessed by anything outside that
ecosystem. If I understand correctly, Cinnamon has muffin (a fork of
mutter) and cinnamon itself (a fork of gnome-shell) which have a similar
relationship; but perhaps the Cinnamon ecosystem is even simpler than
GNOME's, because GNOME has extensions and I don't think Cinnamon does?
I think libmuffin-dev also probably should not be installing its GIR
XML into /usr/share/gir-1.0, because most (all?) of muffin's GIR XML
consists of forks of other projects (Clutter, Cogl, Metacity) and it
seems confusing to have GIR XML in the public search path that is named
something like "Clutter" but is actually a private fork of a better-known
library. src:mutter puts its GIR XML in /usr/lib/MULTIARCH/mutter-12,
which is the same directory as the private typelibs and the private
shared libraries. I think it would make sense for muffin to do the
equivalent, by putting its GIR XML into /usr/lib/MULTIARCH/muffin.
On Sat, 09 Dec 2023 at 21:12:03 +0100, Fabio Fantoni wrote:
> Thanks for all informations, I did some changes in git, moved gir files in
> /usr/share/cinnamon
I see that you are also now running dh_girepository as:
dh_girepository ... /usr/share/cinnamon
Was that so that when dh_girepository looks at
/usr/lib/MULTIARCH/cinnamon/{St-1.0,Cinnamon-0.1}.typelib, it will be able
to find their corresponding GIR XML in
/usr/share/cinnamon/{St-1.0,Cinnamon-0.1}.gir?
Or is there some other reason that you needed to tell dh_girepository about
this private directory?
src:gnome-shell doesn't actually run dh_girepository at all (although
src:mutter does). I'm not sure whether src:gnome-shell or src:cinnamon
is the one that is being more correct here. Ideally dh_girepository would
"do the right thing" for both public and private libraries, but it isn't
100% clear to me what the right thing *is* in this case.
> the package for the split should be cinnamon-dev, with only gir I thinked
> gir1.2-cinnamon-0.1-dev, what is correct and/or best?
Let me go back a few steps from there:
- Is there anything else in Debian that is going to use this GIR XML
programmatically?
- If something else in Debian wanted to load libcinnamon.so or libst.so,
are there C/C++ headers that it would be able to use to access those
libraries? GIR XML is analogous to C/C++ headers, so if these libraries
are "private enough" that you wouldn't want third-party code to be able
to #include their headers, you probably also don't want third-party code
to be loading their interface descriptions from GIR XML either?
- Do you *want* a separate -dev package? Or are you just suggesting this
because dh_girepository suggests a dependency cinnamon -> libmuffin-dev,
which you actively don't want?
- Is there anything else installed by src:cinnamon that conceptually
"belongs" in a -dev package, and is not needed by end users? Like for
example C/C++ header files that I've missed, or perhaps developer-only
tools?
It isn't completely obvious to me why either GNOME Shell or Cinnamon
installs its GIR XML at all - I can't immediately think of any situation
where it would be useful, except perhaps to a GNOME Shell or Cinnamon
developer who is already building the relevant project from source and
could equally well just look at the .gir file in their build tree. But
perhaps you know a reason why installing the GIR XML is useful?
It might help you to decide this if I explain the reasoning for
introducing the gir1.2-foo-1-dev package names.
Briefly, the idea is that on systems that don't need GObject-Introspection,
we want to be able to build with DEB_BUILD_PROFILES=nogir and have the
GObject-Introspection (both typelibs and GIR XML) disappear. This would be
particularly useful when we're bootstrapping new architectures and the
new architecture's GObject-Introspection tools don't necessarily exist yet.
We don't want to just delete the typelibs and GIR XML, because ideally,
all of our build profiles should be "safe": if I build a libgtk-4-dev
package with or without DEB_BUILD_PROFILES=nogir, its contents should
ideally be identical. Or, if we can't have that, the next best thing would
be for it to have Provides: gir1.2-gtk-4.0-dev if the GIR XML is present,
but have that Provides disappear if it was built with
DEB_BUILD_PROFILES=nogir, so that dependent packages can use
Build-Depends: gir1.2-gtk-4.0-dev to indicate "I need GTK's GIR XML".
See https://bugs.debian.org/1030223 for more on this topic.
For cinnamon, am I correct to think that the Cinnamon desktop shell (its
closest equivalent of GNOME Shell) always requires Cinnamon-0.1.typelib
for basic runtime functionality, and similarly, cinnamon-screensaver
requires CScreensaver-1.0.typelib?
If that is true, then making these packages support
DEB_BUILD_PROFILES=nogir probably wouldn't make any sense anyway:
there's no point in having a way to build a version of Cinnamon that
doesn't actually do anything useful, so building them without typelibs
is unnecessary (even harmful). Similarly the GIR XML is produced as a
side-effect of building the typelibs, so any time we can produce a
useful/working version of Cinnamon, it's going to have GIR XML available.
I would also tend to think that it would be weird to have a package that
is named gir1.2-cinnamon-0.1-dev, but does not provide Cinnamon-0.1.gir
in the default (public) library search path. So *if* you have a separate
-dev package, I would lean towards naming it cinnamon-dev.
But I don't think a separate -dev package is necessarily even desirable
here. If cinnamon isn't installing things like C/C++ headers, then I
have to wonder whether the GIR XML would be directly usable by
GObject-Introspection tools, even if libmuffin-dev is also installed?
If the GIR XML is only being installed for reference or for some sort
of manual use, then that probably doesn't justify a separate -dev package:
I think the reasonable options would be installing it into a package that
already exists for some other reason (cinnamon or cinnamon-common), or
not installing it at all.
> about needed -dev deps for gir, that in cinnamon package is not good
I agree, and cinnamon's situation is not one that I was thinking of while
updating dh_girepository.
What I want here is that for *public* GIR XML, if I have installed GIR
XML with a dependency (like for example Gdk-4.0.gir, which contains
<include name="Pango" version="1.0"/>), then that will pull in the
appropriate package that contains the <include>'d dependency (for example
Pango-1.0.gir). This is because libgirepository will refuse to process
GIR XML if it cannot follow all the <include>s, similar to a C compiler
refusing to process <gdk/gdktypes.h> if it can't follow the
"#include <pango/pango.h>" directive.
For *private* GIR XML, like yours, it's less obvious what should happen.
Clearly the hard dependency is appropriate for a package that is
"mostly" used for development and compiling, but cinnamon.deb and
cinnamon-common.deb are not mostly for development: instead, they're
mostly for end-user systems, and having the GIR XML is an afterthought.
So I agree that we don't want a libmuffin-dev dependency here.
Some ideas that might help your situation:
- We could add a --no-dev-dependencies option to dh_girepository, which
would prevent it from parsing the GIR XML for <include> dependencies
and adding them to ${gir:Depends}?
- Or we could make it stop generating those dependencies if the GIR XML is
in a private directory?
- Or we could give it an option similar to dpkg-shlibdeps -dSuggests, which
would let you downgrade the ${gir:Depends} to a ${gir:Suggests}?
- Or perhaps you have a better idea?
> can [we] still remove [the -dev dependencies] or would it just be a
> temporary thing until
> the split into a new package but normally they must be present? (so sooner
> or later the separate package that has them must be made sooner or later)
For private GIR XML, as said above, I don't really know the answer to this.
If there is eventually going to be a separate -dev package, then I think
that it should have Depends: libmuffin-dev. My rationale for that is that
if I install cinnamon-dev, I want it to have enough dependencies that I can
do "the main purpose of cinnamon-dev", which in this case is compiling ...
something. (I don't know - what would I compile with it? Some sort of
equivalent of GNOME Shell extensions?)
But I'm really not sure who or what a separate -dev package would be for?
> user testing cinnamon 6 on sid spotted -dev package in
> gir1.2-cscreensaver-1.0 actually not present, so I suppose added from recent
> dh_girepository changes. upstream have all in libcscreensaver0, so I created
> at least gir1.2-cscreensaver-1.0 in 5.4.1-2 to solve the policy issue (I not
> tried to do a PR for upstream now) but I put also gir file in it instead
> create -dev package for only it. I must create gir1.2-cscreensaver-1.0-dev
> with gir and all needed -dev deps or is possible remove the -dev deps?
Specifics of cinnamon-screensaver are a bit off-topic for a bug against
the cinnamon source package, so I'm going to open a separate bug against
gir1.2-cscreensaver-1.0 and reply there, if that's OK?
On a cinnamon git commit on Salsa, Fabio also wrote:
> I thinked to move gir files of cinnamon to cinnamon-common as
> don't have arch-dep path and similar to gnome-shell, also decrease difference
> with upstream packaging but when I added to cinnamon instead I found:
>
> https://lintian.debian.org/tags/gir-in-arch-all-package
> GObject-Introspection XML files (/usr/share/gir-1.0/Foo-23.gir) must be
> made available in an architecture-dependent package of the same source.
> Is gnome-shell correct to have in -common package? Or this rules is only
> for public gir and not private?
As far as I know, this rule is actually only needed for packages that
will run dh_girepository (dh-sequence-gir), which gnome-shell doesn't
do. I think packages wth public GIR XML should follow this rule even if
they don't run dh_girepository, but packages with private GIR XML don't
necessarily need to.
I believe the only reason for this rule is a dh_girepository limitation.
To find out what the dependencies of a typelib are, it looks for the
corresponding GIR XML, which is easier to parse than the binary typelib.
To do that, it looks for the GIR XML in binary packages' build directories
(debian/cinnamon/, debian/cinnamon-common/ and so on). But when your
package is built on a particular architecture's buildd (let's say amd64),
architecture-specific binary package build directories like
debian/cinnamon/ will exist, but architecture-independent binary package
build directories like debian/cinnamon-common/ won't.
I'm hoping that I can resolve that limitation by one of these two
strategies:
- making dh_girepository run a tool similar to g-ir-inspect to parse the
dependencies out of the binary typelib;
- or looking for the GIR XML in debian/tmp/ so that it doesn't matter
whether it was actually included in a binary package or not
either of which I think would make this rule unnecessary.
smcv
