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

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 05:47PM +03, Sebastian Dröge wrote:

>
> 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.

Thank you for taking the time to write this up.

> 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.
>
> [...]
>
> 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.

Sounds like this is off the table if they're not something you'd edit.

>  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.

Would you ever accept patches upstream to the generated files?  If you'd
want them to be reworked as patches to the generating files, then the
generated files aren't in their preferred form for modification, which
means we can't consider them source.

By contrast, if you'd generated the files once and then that's what you
now work with upstream, then (iii) is fine.  Hope that makes sense.

Btw, the requirement that we can regenerate the files using tools in
Debian main is non-negotiable, but they do not have to actually *be*
regenerated at package build time.  That can help in finding solutions
to these kinds of complexities.

> 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.

Right, the generated Rust is  more significant than the .gir issue 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.

It needs to be packaged, afaict.

> 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.

The ftpteam doesn't significantly disagree about what is acceptable, but
we do make mistakes.  Given our extremely limited manpower, the only
feasible policy is that the contents of the archive does not count as a
precedent.

> 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.

Yes, (without having looked at the packages myself) sounds like these
bugs should be filed.

-- 
Sean Whitton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 869 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20220821/7c944d87/attachment.sig>