On Sun, Apr 30, 2023 at 9:17 AM Julian Sikorski <belegdol(a)gmail.com> wrote:
Hello,
I looked into updating libopenraw to 0.3.5 yesterday, in order to
possibly enable packaging miniaturo [1], a drop-in replacement for the
unmaintained raw-thumbnailer [2].
Hi!
From a first look, packaging miniature should be possible, but it will
require packaging a few dependencies, as you already found out.
I can help with getting miniaturo and its dependencies packaged, if you want?
It's not looking like a "simple" starting point for a first-time Rust
packager, but for example, I can submit the packages for review and
you review them, if that works for you?
During the build process, libopenraw tries do download mp4parse and
mp4parse_capi, which works if --enable-network is passed to mock. For a
proper update I assume these dependencies would need to be packaged
first. mp4_parse even used to have a fedora package at some point in the
past [3].
The question is: what would the proper way of packaging the updated
libopenraw? How to tell it to use the system versions of the libs?
Yes, downloading from the internet is the "default mode of operation"
of cargo. You will need to add the "%cargo_prep" macro at the end of
the %prep scriptlet.
This macro drops a cargo configuration file into ./.cargo/config which
makes it look for Rust sources as they are packaged instead of loading
them from the internet.
Additionally, adding a %generate_buildrequires section will be needed,
where "%cargo_generate_buildrequires" needs to be run in the root
directory of the Rust subproject.
This causes the build system to pull in all necessary Rust dependencies.
The only problem I see is that the build system apparently patches
mp4-parse after download. This isn't compatible with how we package
things for Fedora (i.e. you can't just patch random third-party
library before running a build), so that will need to be dropped (but
our Fedora package for the patched crate will likely contain a similar
patch anyway).
The guidelines appear to be focused on pure rust packages. And, even
more
importantly: would miniaturo be even allowed to be packaged? There
appears to be no package at crates.io. Thanks for the input.
Packaging miniaturo is fine. It doesn't provide a Rust library
interface (i.e. an "importable crate"), so the requirement for it to
be published on crates.io does not apply. (Maybe the language for this
in the Packaging Guidelines isn't 100% obvious, sorry about that ...)
The current Rust Packaging Guidelines were written at a point in time
when almost all Rust projects that were getting packaged were "crates"
published on crates.io. This is no longer true, since many projects
started including Rust code (mesa, libblkio, firefox, thunderbird,
mozjs, rpm-ostree, gnome-tour, librsvg2, etc.) ...
I've been attempting to overhaul the Rust Packaging Guidelines to
reflect this fact (and make them more "descriptive" and less
"prescriptive", since the rust2rpm tool is basically an implementation
of the Rust Packaging Guidelines for Rust crates anyway), but I
haven't had much time work on this rewrite lately. :(
Let me know how you want to proceed. My offer to help packaging things
stands. But if you want to get started with Rust packaging yourself,
I'd recommend starting with some simple crates rather than jumping
head first into complicated multi-language projects like libopenraw :)
Fabio