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

[Sebastian Dröge]

Hi,

Thanks for your fast response!

On Sun, 2022-08-21 at 10:49 -0700, Sean Whitton wrote:
> > 
> > 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.

Patches to the generated Rust files only as a hotfix that should be
fixed properly in either

  - the code generator (gir)
  - gobject-introspection (tool that generates the .gir files)
  - the C code

Patches to the generated .gir files only as hotfix or if any other
approach is not feasible in the medium-term, see fix.sh that I
mentioned in the previous mail.

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

The Rust source files are regularly regenerated upstream whenever there
are changes in the C API (i.e. in the .gir files) or in the code
generator.

All changes to the generated code are carefully reviewed and only if
they all make sense the result is committed. This ensures that there
are no regressions anywhere.

This is also why completely automating this process without human
review along the way is not going to work well.

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

So this basically would mean that in the least, each of the packages
mentioned needs to ship

  - the exact versions of the C code of every relevant library
  - the exact version of gobject-introspection that was used for
    generating the .gir files
  - the exact version of the gir code generator used for generating
    the Rust code

Note that the versions might differ between different packages, e.g.
latest rust-gtk might use a different (but API-compatible) version of
the code generator than rust-gstreamer.

This seems possible to do but not really scalable or sensible. Also you
would probably complain that there are many different copies of the
same code in different versions in the source packages.

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

Why? The .gir file contains the same information as the e.g. rust-
gstreamer-sys src/lib.rs file in a different format.

For rust-gstreamer src/auto/*.rs it's a bit more complicated of course,
there the code generator and the corresponding Gir.toml configuration
actually do non-trivial "interpretation" of the .gir files.


From my understanding, the only thing that qualifies as "original
source" here is the C source code of the libraries in combination with
the tools and configuration files to generate the Rust sources.


It's also quite absurd that none of these problems would exist in the
case where all these files were actually manually written, which was
the case until a couple of years ago. Of course this had other,
technical disadvantages like silly copy&paste bugs.

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

Then you'll have to very carefully do versioning on the Debian
packaging-side and have multiple versions in the archive. Doable but
that's your (plural) job as package maintainers then.

Also all the other steps above are of course doable but they put a lot
of burden on the package maintainers, so likely mean that many of these
things are not going to be packaged in Debian.

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

That makes sense but it's still curious that these things never were a
problem for about two decades at this point. You would've thought that
someone would've noticed at some point.

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

Sure, I can do that in the next for the Rust and non-Rust packages I
mentioned but it will probably cause a not very small amount of
unhappiness.

If the end result is that it's not really feasible to package any of
these packages for Debian then I guess that's just how it is until
these rules are updated for "modern" (i.e. 20 years, see gtk-sharp)
practices.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20220821/a388824e/attachment.sig>