Bug#1059341: gir1.2-cscreensaver-1.0: contains 900K of GIR XML which shouldn't usually be necessary on end user systems

2024-07-09 Thread Simon McVittie
On Tue, 09 Jul 2024 at 12:32:22 +0200, Fabio Fantoni wrote:
> Il 22/12/2023 23:26, Simon McVittie ha scritto:
> > On #1057391, Fabio Fantoni wrote:
> > > 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?
> >
> > If I'm understanding the question correctly, the right answer depends
> > on whether this is a public or private library.
>
> Hi, I tried to report this upstream but in new version instead make the
> library "fully public" or "fully private" have simply removed thr gir file: 
> https://github.com/linuxmint/cinnamon-screensaver/commit/97fcf5d163f45de89159db110462d340dc736acf

Please try to get clarification on whether the shared library is
considered to be public (usable by external source packages) or private
(incorrect to use outside the cinnamon-screensaver source package).
It seems like it should be one or the other of those, and I can't give
concrete recommendations without knowing which one.

>From the dependencies I can see in Debian, my best guess would be that
it's probably private, because there is no -dev package that third-party
users of the library could use to link to it, and there is nothing that
Build-Depends on any component of it either?

If it's private, then the packaging could become even simpler
than upstream's, by moving the library and typelib into private
directories and merging everything from libcscreensaver0_*.deb and
gir1.2-cscreensaver-1.0_*.deb into cinnamon-screensaver_*.deb.

> Is it acceptable to remove it in Debian packages too or would it be an
> unacceptable worsening?

I cannot answer this question, because I don't know whether other packages
in Debian require this GIR XML file.

Perhaps remove it and see whether the rest of Cinnamon still compiles
and works as intended?

smcv



Bug#1059341: gir1.2-cscreensaver-1.0: contains 900K of GIR XML which shouldn't usually be necessary on end user systems

2024-07-09 Thread Fabio Fantoni

Il 22/12/2023 23:26, Simon McVittie ha scritto:

Package: gir1.2-cscreensaver-1.0
Version: 5.8.1-2
Severity: normal
X-Debbugs-Cc: gobject-introspect...@packages.debian.org

In addition to the binary typelib (about 50K), gir1.2-cscreensaver-1.0
contains GIR XML (about 900K). This is not right for the conventional
way to package GObject-Introspection modules, and is probably a waste of
space on end-user systems.

Typelib files are normally used by bindings for dynamic languages like
Python (PyGI), JavaScript (gjs, cjs, seed) or Perl
(Glib::Object::Introspection), as an equivalent of a C/C++ shared library.
If I understand correctly, cinnamon-screensaver is mostly written in Python,
and uses C code from libcscreensaver0 via gir1.2-cscreensaver-1.0 and PyGI.

GIR XML is normally used by bindings for static languages like C++, Rust
or Haskell, and are closer to an equivalent of C/C++ header files. They
contain a superset of the information in the equivalent typelib file,
in a less efficient but easier-to-parse encoding. I suspect that
cinnamon-screensaver doesn't actually need this.

On #1057391, Fabio Fantoni wrote:

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?

If I'm understanding the question correctly, the right answer depends
on whether this is a public or private library.

I see that the way src:cinnamon-screensaver packages its shared library
libcscreensaver0 seems to be a mixture of public and private library,
which might indicate some confusion about its role. Is this library
private to src:cinnamon-screensaver and not intended to be used by other
packages? Or is it a public library that can be used by third-party
software, like GTK or libsoup? Or is there some more complicated situation?

If it's a private library
=

One option is to say that it's a private library, like the libgc.so
that is part of src:gnome-characters.

If it's this, then:

- the shared library should be in a non-default library path, like maybe
   /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
   (gnome-characters uses /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/)
   and the main executable should use the LD_LIBRARY_PATH environment
   variable, a DT_RUNPATH ELF header (gcc -Wl,-rpath), or
   g_irepository_prepend_library_path() to load it

- the typelib should also be in a non-default location, like maybe
   /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
   (gnome-characters uses
   /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/girepository-1.0/),
   and the main executable should use the GI_TYPELIB_PATH environment
   variable or g_irepository_prepend_search_path() to load it

- it's correct for the C/C++ header files not to be installed

- the GIR XML should either not be installed, or be installed in a
   non-default location, like maybe /usr/share/cinnamon-screensaver/

- everything can be in one large binary package

- it's probably unnecessary to run dh_girepository, because everything
   is in one large binary package anyway - although you will want to depend
   on gir1.2-gtk-3.0, either via dh_girepository or directly

src:gnome-characters seems to be a good example of this setup.

If it's a public library


Another option is to say that it's a public library, like the libcheese.so.*
and libcheese-gtk.so.* that are part of src:cheese.

If it's this, then:

- the shared library should continue to be in
   /usr/lib/${DEB_HOST_MULTIARCH}/ in a libcscreensaver0 binary package

- the typelib should continue to be in
   /usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0/ in a
   gir1.2-cscreensaver-1.0 binary package

- the C/C++ header files should be installed in a new -dev package,
   probably libcscreensaver-dev, so that other C/C++ code can link to the
   library

- the GIR XML should continue to be in /usr/share/gir-1.0/ but should be
   moved into the new -dev package, which should have Depends: ${gir:Depends}
   and Provides: ${gir:Provides}

- multiple, separate binary packages will be needed

- dh_girepository should be used

src:flatpak is a good example of this setup.

If it's something more complicated
==

If there's some more complicated situation, like the forks of Clutter and
Cogl in src:mutter and src:muffin, then please explain, and I or other
members of the GNOME team can try to come up with a recommendation.

Thanks,
 smcv

Hi, I tried to report this upstream but in new version instead make the 
library "fully public" or "fully private" have simply 

Bug#1059341: gir1.2-cscreensaver-1.0: contains 900K of GIR XML which shouldn't usually be necessary on end user systems

2023-12-22 Thread Simon McVittie
Package: gir1.2-cscreensaver-1.0
Version: 5.8.1-2
Severity: normal
X-Debbugs-Cc: gobject-introspect...@packages.debian.org

In addition to the binary typelib (about 50K), gir1.2-cscreensaver-1.0
contains GIR XML (about 900K). This is not right for the conventional
way to package GObject-Introspection modules, and is probably a waste of
space on end-user systems.

Typelib files are normally used by bindings for dynamic languages like
Python (PyGI), JavaScript (gjs, cjs, seed) or Perl
(Glib::Object::Introspection), as an equivalent of a C/C++ shared library.
If I understand correctly, cinnamon-screensaver is mostly written in Python,
and uses C code from libcscreensaver0 via gir1.2-cscreensaver-1.0 and PyGI.

GIR XML is normally used by bindings for static languages like C++, Rust
or Haskell, and are closer to an equivalent of C/C++ header files. They
contain a superset of the information in the equivalent typelib file,
in a less efficient but easier-to-parse encoding. I suspect that
cinnamon-screensaver doesn't actually need this.

On #1057391, Fabio Fantoni wrote:
> 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?

If I'm understanding the question correctly, the right answer depends
on whether this is a public or private library.

I see that the way src:cinnamon-screensaver packages its shared library
libcscreensaver0 seems to be a mixture of public and private library,
which might indicate some confusion about its role. Is this library
private to src:cinnamon-screensaver and not intended to be used by other
packages? Or is it a public library that can be used by third-party
software, like GTK or libsoup? Or is there some more complicated situation?

If it's a private library
=

One option is to say that it's a private library, like the libgc.so
that is part of src:gnome-characters.

If it's this, then:

- the shared library should be in a non-default library path, like maybe
  /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
  (gnome-characters uses /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/)
  and the main executable should use the LD_LIBRARY_PATH environment
  variable, a DT_RUNPATH ELF header (gcc -Wl,-rpath), or
  g_irepository_prepend_library_path() to load it

- the typelib should also be in a non-default location, like maybe
  /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
  (gnome-characters uses
  /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/girepository-1.0/),
  and the main executable should use the GI_TYPELIB_PATH environment
  variable or g_irepository_prepend_search_path() to load it

- it's correct for the C/C++ header files not to be installed

- the GIR XML should either not be installed, or be installed in a
  non-default location, like maybe /usr/share/cinnamon-screensaver/

- everything can be in one large binary package

- it's probably unnecessary to run dh_girepository, because everything
  is in one large binary package anyway - although you will want to depend
  on gir1.2-gtk-3.0, either via dh_girepository or directly

src:gnome-characters seems to be a good example of this setup.

If it's a public library


Another option is to say that it's a public library, like the libcheese.so.*
and libcheese-gtk.so.* that are part of src:cheese.

If it's this, then:

- the shared library should continue to be in
  /usr/lib/${DEB_HOST_MULTIARCH}/ in a libcscreensaver0 binary package

- the typelib should continue to be in
  /usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0/ in a
  gir1.2-cscreensaver-1.0 binary package

- the C/C++ header files should be installed in a new -dev package,
  probably libcscreensaver-dev, so that other C/C++ code can link to the
  library

- the GIR XML should continue to be in /usr/share/gir-1.0/ but should be
  moved into the new -dev package, which should have Depends: ${gir:Depends}
  and Provides: ${gir:Provides}

- multiple, separate binary packages will be needed

- dh_girepository should be used

src:flatpak is a good example of this setup.

If it's something more complicated
==

If there's some more complicated situation, like the forks of Clutter and
Cogl in src:mutter and src:muffin, then please explain, and I or other
members of the GNOME team can try to come up with a recommendation.

Thanks,
smcv