Upcoming retirement of unused compat packages for Rust crates
by Fabio Valentini
Hi all,
I'm planning to do another round of removals of unused Rust crates -
at first. focusing only on compat packages which are no longer useful
since they have no remaining dependent packages in Rawhide.
This includes the gtk-rs v0.16 / gtk4-rs v0.5 compat packages:
- rust-atk0.16
- rust-atk-sys0.16
- rust-cairo-rs0.16
- rust-cairo-sys-rs0.16
- rust-gdk0.16
- rust-gdk-sys0.16
- rust-gdk-pixbuf0.16
- rust-gdk-pixbuf-sys0.16
- rust-gio0.16
- rust-gio-sys0.16
- rust-glib0.16
- rust-glib-sys0.16
- rust-glib-macros0.16
- rust-gobject-sys0.16
- rust-graphene-rs0.16
- rust-graphene-sys0.16
- rust-gtk0.16
- rust-gtk-sys0.16
- rust-gtk3-macros0.16
- rust-pango0.16
- rust-pango-sys0.16
- rust-pangocairo0.16
- rust-pangocairo-sys0.16
- rust-gdk4_0.5
- rust-gdk4-sys0.5
- rust-gsk4_0.5
- rust-gsk4-sys0.5
- rust-gtk4_0.5
- rust-gtk4-sys0.5
- rust-gtk4-macros0.5
- rust-libadwaita0.2
- rust-libadwaita-sys0.2
Side note: The compat packages for the even older gtk-rs v0.15 /
gtk4-rs v0.4 / libadwaita-rs v0.1 cannot be removed yet, since
squeekboard and system76-keyboard-configurator still depend on these
obsolete versions ... :sad face:
Additional (unrelated to gtk-rs) compat packages which are no longer needed:
- rust-libudev0.2
- rust-memmap2_0.3
- rust-cargo_metadata0.12
- rust-tui0.9
- rust-ansi-str0.5
All listed packages are compat packages with newer versions of these
projects already being available in Fedora 37+, and all listed
packages have no dependent packages left. If anybody has objections to
retiring any of these packages despite this, please notify me within
the next 7 days, as I plan to process the retirement of all packages
listed in this email next Monday (June 5).
Fabio
3 months, 2 weeks
Re: How to deal with packages cointaining rust parts?
by Fabio Valentini
On Sun, Apr 30, 2023 at 1:31 PM Julian Sikorski <belegdol(a)gmail.com> wrote:
>
> 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
This is caused by using pushd / popd instead of "cd", because pushd
and popd print things to stdout that %generate_buildrequires
interprets as names of dependencies ... you can use plain "cd"
instead.
> 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.
It doesn't look like a problem, the patch here looks harmless:
https://gitlab.freedesktop.org/libopenraw/libopenraw/-/blob/master/lib/mp...
> 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.
I took a look at the libopenraw spec file, and after fixing the
pushd/cd thing, the biggest problem I see is more of an upstream
problem ...
It bundles copies of the mp4parse and mp4parse_capi crates (no idea
whether the sources are just included or if they are forks with
downstream changes), in addition to 15 MB of vendored Rust
dependencies, which we cannot use for Fedora builds.
If the mp4parse{,_capi} sources are indeed forks with downstream
patches, it would be ok to leave them as they are, but the vendored
Rust dependencies need to be removed and can't be used. Honestly, the
entire Rust part of libopenraw [0] looks very "hackish" and ad-hoc
(it's not even a proper cargo workspace - which our Rust packaging
tools support - but disconnected crates that are held together by
path-based dependencies - which our tools *don't' support).
I'll try to make the package build ~somehow~, but I can't make any
promises right now :)
Fabio
[0]: https://gitlab.freedesktop.org/libopenraw/libopenraw/-/tree/master/lib/mp4
4 months, 3 weeks