[Pkg-rust-maintainers] Need help packaging loop-rs and gst-plugin-rs

[Wolfgang Silbermayr]

On 8/29/21 12:52 AM, Joshua Peisach wrote:
> Hello Rust crate packaging maintainers,

Hi Joshua,

Welcome!

> I've been trying to package loop-rs and gst-plugin-rs, both of which have RFP
> bugs in WNPP. However, I think debcargo may be messing up dependencies by
> adding extra flags to the dependency names.

I did a quick test for loop-rs, and debcargo seems to do what I'd expect it to
do. Because that might be rather confusing an difficult to understand at
first, I try to explain it.

> First, I've tried using my normal Ubuntu Hirsute installation for development
> (which is what I normally use), but then I realized that debcargo was making
> all these packages with names that I couldn't install. They did exist but they
> had a +1-default, or something similar to that before the typical -dev suffix.
> I even did try a sbuild in a schroot, and with no success, even trying to
> ignore the missing build deps, I set up a Debian unstable virtual machine to
> still no success. I'm not sure if this is a bug or if I'm doing something
> wrong, but I'm having issues getting the correct dependencies.

One example that shows why things go wrong might be the `humantime` dependency
of `loop-rs`. First off, `loop-rs` requires `humantime` 1.1.1 whereas we
currently have packaged 2.0.0 of it in Debian which is also what is available
in hirsute. Therefore, `loop-rs` adds to its `Build-Depends` field a
dependency on `librust-humantime-1+default-dev (>= 1.1.1-~~)`. Simplified,
that means it requires the `default` feature of the `humantime` crate source
in major version `1`, minimum full version requirement is `1.1.1`.

If you take a look at the description of the binary package
`librust-humantime-dev`, you'll see - among others - the following entries in
the `Provides` field:

librust-humantime-2-dev (=2.0.0-1)
librust-humantime+default-dev (= 2.0.0-1)
librust-humantime-2+default-dev (= 2.0.0-1)
…

If the `humantime` dependency of `loop-rs` was updated to 2.0.0, the
`Build-Depends` field entry would change to `librust-humantime-2+default-dev
(>= 2.0.0-~~)`. Then the available `librust-humantime-dev` package we have
would satisfy that requirement through its `Provides`.

After getting burnt initially by some technical problems, we decided to avoid
packaging previous versions of crates in parallel to the latest releases, even
though the tooling would support it by creating e.g. a "real"
`librust-humantime-1-dev` package. So my advice would be to ask upstream about
updating their dependencies, possibly sending them a patch or a merge request.
In case they don't react or don't accept it (or if you'd like to go faster),
we can still add a patch to the Debian package.

Please be aware that this is just a single item that I quickly dived into,
you'll find more of them for sure. Without having taken a deeper look, I guess
that `gst-plugin` will possible require an update of `gstreamer` blocked by an
update of a few `futures-*` crates to version 0.3. We have 0.1 of those at the
moment, and the update will be a major undertaking as it touches many parts of
the ecosystem.

> I don't see any valid reason debcargo would create these extra flags that will
> mess up my apt installation, and even installing the correct package names
> obviously won't get dpkg-checkbuilddeps working (unless it is supposed to?),
> so what is going on? What am I missing?

See above.

> Otherwise, the only other concern I have is for loop-rs. Shouldn't the package
> be named 'loop' instead of 'rust-loop-rs' or just 'loop-rs' since this is a
> small binary application?

I'd expect the source package to be called `rust-loop-rs`, because that
matches the pattern of all Rust packages that we build from the source
published to crates.io. You can change the name of the binary package as
described below, although I'd be careful when claiming such a generic name as
`loop` with frequent usage in computer science, some discussion e.g. on the
debian-devel list would make sense in this specific case.

> Anyways, is there some way to override debcargo or whatnot? What is the proper
> thing to do? What am I doing wrong? I'd love to get these packaged.

In general, you can override a bunch of settings using a config file that
usually gets placed in the source package as `debian/debcargo.toml`. There you
can set the `bin_name` entry.

Now that I told lots of details, there is one more important piece of
information that might be of interest to you: Nowadays we hardly ever directly
run `debcargo`, but instead we have a bunch of scripts that we run to do the
legwork for us, including building and autopkg-testing the package inside an
schroot environment. They are part of the `debcargo-conf` repository [0] which
is where we maintain the metadata for most of the Rust crates packaged in
Debian (and therefore Ubuntu). You might want to experiment with the
repository, and read the `*.rst` files there. You'll find some more
documentation at [1] and [2].

I hope I don't discourage your motivation by telling you that things don't
work as you expected them to, but really packaging Rust crates is a lot of fun
in the end, it's just that the packages you want to create need some more work
and knowledge than others which might go smooth right from the start, and in
addition there are blockers which need to be eliminated first.

I added debian-rust at lists.debian.org to the receivers. Because the
pkg-rust-maintainers mailing list is "spammed" by bot messages (e.g.
successful or rejected uploads), we decided to crate that one in addition for
communication with humans only.

Feel free to join #debian-rust on OFTC in case you need some guidance when
attempting to create the packages and you get stuck. Most of the time, there
are some supportive users in the channel willing to help.

Best regards,
Wolfgang.

--

[0] https://salsa.debian.org/rust-team/debcargo-conf
[1] https://blog.hackeriet.no/packaging-a-rust-project-for-debian/
[2] https://wiki.debian.org/Teams/RustPackaging