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
9 months, 3 weeks
How to deal with packages cointaining rust parts?
by Julian Sikorski
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].
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? 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.
Best regards,
Julian
[1] https://github.com/dbrgn/miniaturo
[2]
https://gitlab.freedesktop.org/libopenraw/libopenraw/-/issues/14#note_189...
[3] https://src.fedoraproject.org/rpms/rust-mp4parse
11 months