Am 30.04.23 um 12:35 schrieb Fabio Valentini:
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
Hi,
thanks for the detailed feedback! The reason I wanted to give it a shot
was the issue reported with raw_thumbnailer [1]. I am already
co-maintaining libopenraw, so I thought I could at least try.
So far I managed to get packages for mp4parse, mp4parse_capi, criterion
and bitreader building, see attached. I also managed libopenraw not to
fail at attempting to go online, but I am not sure how to solve the
error I am getting now:
error: Dependency tokens must begin with alpha-numeric, '_' or '/':
~/build/BUILD/libopenraw-0 .3.5/lib/mp4 ~/build/BUILD/libopenraw-0.3.5
I am also not sure I will be able to get rid of the patching. At the
first glance it requires understanding what the patches are doing and
knowing how to replace the functionality.
If you would be willing to pick up where I left, I can definitely offer
to do the package reviews. I am just worried I would not be able to help
much beyond that, saving for keeping the packages up-to-date and liasing
with their upstreams. But it definitely looks like you are right and I
have bitten off more than I can chew.
Best regards,
Julian
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=2165576