[Pkg-rust-maintainers] rust-gestreamer-player sys license questions

[Sebastian Dröge]

Hi,

As it seems like there's no progress in any useful direction, I decided
to explain the whole process and situation here in my role as upstream
of the affected package.

While it is clearly true that the package does not contain "the
original source", let's discuss what the process is to get from "the
original source" to the content of the packages and what consequences
that has in the context of Debian.


1. GIR XML files with API definitions
-------------------------------------

The first step here is to generate the GIR XML files that contain the
API definition of the C library in a machine-readable format.

This is done as part of the build process of the C library via GObject
Introspection[0] and involves parsing the C code, headers and also
running some code against the library

[0] https://gitlab.gnome.org/GNOME/gobject-introspection/

The result is the .gir file that Debian also ships as part of the -dev
packages of various libraries, e.g. libgstreamer1.0-dev ships
/usr/share/gir-1.0/Gst-1.0.gir .

In theory we could use the .gir files packaged by Debian, i.e.

  libgstreamer-plugins-bad1.0-dev:amd64: /usr/share/gir-1.0/GstPlayer-1.0.gir

in case of the package we're talking about here, however:

  a) The version in Debian is older than what was used for the rust-
     gstreamer-player-sys release so some API is missing.
  b) The version in Debian doesn't have various bugfixes that are
     available in newer versions so the generated bindings would have
     bugs compared to the generated file that is in the source package.
  c) The .gir files are post-processed to fix various issues via a
     shell script:
       https://gitlab.freedesktop.org/gstreamer/gir-files-rs/-/blob/main/fix.sh
  d) The generated code would be different between the actual release
     and what Debian ships. I'm not going to support this upstream as
     it's a waste of my time to figure out what Debian (or any other
     distro) actually ships and how it differs from the actual tested
     release. I'm fine with you adding bugfixes to those generated
     files, FWIW.

The officially supported versions of the .gir files are available in
the upstream git repository under the relevant release tags as a git
submodule:
  https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/
See the gst-gir-files submodule.

So for this part there are 3 options I see

  i) You ship the supported .gir files with the source packages in
     Debian and consider them the "original source". It obviously isn't
     and honestly it's harder to edit those XML files than to edit the
     generated Rust code.

     Note that this means to not just ship the single GstPlayer-1.0.gir
     but also all the dependencies of it that you can find in the same
     git repository.

 ii) You build the exact versions of the C libraries as part of the
     package and get the .gir files from that.

     Note that this means to also build all dependencies of GStreamer,
     like GLib/GObject, in the correct versions.

iii) You consider the generated Rust source file as an interface
     definition and the "original source" itself. In the end it's
     not very different to a C header file, it just contains more
     information.

 iv) You simply don't package this in Debian.

Note also that this does not only affect the rust-gstreamer-player-sys
package but exactly the same set of .gir files is needed for the rust-
gstreamer-player package that would follow. All files in src/auto in
there are autogenerated too.

And similarly this affects e.g. rust-glib-sys, rust-gtk-sys, rust-
gstreamer-sys, and many others that were actually accepted.


2. Generated Rust source code
-----------------------------

The above-mentioned .gir files are passed through the gir tool:
  https://github.com/gtk-rs/gir

This generates the autogenerated code we're talking about here.

The version of the tool must be the same as the one from the source
release, or otherwise

  a) There will be changes in the generated code, e.g. bugs that were
     already fixed, or incompatible API changes caused by using a newer
     version of the tool.
  b) It might generate wrong code or fail completely if the .gir files
     are not matching the version too. The XML format changes in
     various ways over time and changes in the code generator might be
     needed.

This tool is not packaged in Debian and really shouldn't, but as a
solution here you could ship the exact version needed with the source
package.

Similar to above, if you decide to use a different version than the one
used for the actual release then I'm not going to support this upstream
for the same reasoning: It's a waste of my time to check which versions
every distro actually used for generating the code and I can't really
be sure what code people are actually running.

The version that should be used is again a git submodule inside the
gstreamer-rs repository:
  https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/

Generating all the code, once the prerequisites are in place, is simply
a matter for calling the generator.py script from the repository:
  https://github.com/gtk-rs/gir/blob/master/generator.py


3. Inconsistency in ftp-master decision processes
-------------------------------------------------

As mentioned above already, a couple of packages that have exactly the
same "problem" were accepted and are already since quite some time. It
seems like it all depends on which ftp-master is actually looking at
the package in question, which doesn't seem to be a great situation.

I mentioned various Rust related packages above, and if you decide that
some action is needed for rust-gstreamer-player-sys then the same would
apply to all those packages. As the "problem" is apparently serious
enough to reject the package, these should at least be "serious" bugs
for those other packages that must be fixed before the next Debian
release.

Now so far we talked about Rust-specific packages and I understand that
those are all more "controversial" generally, but the problem we're
discussing here specifically also affects other code.

For example:

  a) The vala source package contains .vapi files. These are literally
     the same as the src/lib.rs of rust-gstreamer-player-sys: an
     autogenerated source file from the .gir files mentioned above.
     Basically the equivalent of a C header file in Vala.

     Nobody had any complaints about vala shipping these files since
     2007 but if rust-gstreamer-player-sys is a problem then something
     has to be done about vala too.

  b) gtk-sharp2 contains e.g. gtk/gtk-api.raw, which is autogenerated
     the same way as the previously discussed .gir files. It's
     basically a predecessor of the .gir format.

     Apparently this was also fine since 2002 already. Nowadays that
     package is basically abandoned so I guess in case this is
     actually a problem it would just be removed directly.

  c) gobject-introspection contains gir/glib-2.0.c (and others) which
     is basically the resulting GLib-2.0.gir file as C comments. This
     file is autogenerated from the C code inside the glib2.0 package.

     Also here, nobody had any complaints about this since 2008 while
     it is exactly the same situation.

     Note that solving this one here has the additional "fun" that
     gobject-introspection also build-depends on glib2.0, so we'd end
     up with a new circular build dependency.

     Also note that if you decide that this is a serious problem then
     this basically affects the whole GNOME desktop and Debian can't
     really ship with GNOME until it's fixed one way or another.

  d) librsvg contains copies of rust-glib-sys, rust-glib, and various
     other packages since version 2.42 (uploaded to Debian in 2018).
     In addition to the code duplication, all the above problems also
     apply here of course.

These are all packages that I already know about and all closely
related to GNOME. I'm sure if I actually look I'll find more instances
of the same in GNOME-related packages but also elsewhere.


Let me know if you have any other questions about any parts in this
mail or related to any of the packages mentioned above.


Thanks,
Sebastian

On Fri, 2022-08-19 at 02:56 +0200, matthias.geiger1024 at tutanota.de
wrote:
> Hi ftp-masters,
> 
> I have some concerns regarding the gstreamer-player(-sys) rust
> package/crate. It has been rejected twice because "not containing any
> code":
> "
> +----------------------+
> | REJECT reasoning |
> +----------------------+
> 
> There is no source code in this package, so it is not DFSG-
> comaptible.
> "
> The code for all gstreamer rust packages are generated the same way
> as stated by the upstream maintainer (slomo):
> 
> "
> ...
> In any case, the lib.rs is generated from the .gir file you found
> there. That's a description of the API of the library and equivalent
> to
> a declarations-only header file, so not really relevant copyright-
> wise
> (see e.g. Google vs. Oracle with regards to Java).
> 
> That XML API description is generated via gobject-introspection from
> the GStreamer C source code (specifically the header files).
> ...
> "
> I already mentioned this is debian/copyright of gstreamer-player-sys.
> From my point of view, I don't see how this violates debian policy,
> especially since the other rust gstreamer packages already in debian
> are "generated" the same way.
> 
> Please advise how I should proceed in this matter. gstreamer-player(-
> sys) is needed for a variety of Rust GNOME applications such as
> Podcasts. 
> 
> Cheers
> 
> Matthias Geiger (werdahias)