Hello,
[Resending as first email was rejected; wasn't a member of the list]
We'd like to package a Rust application for Fedora, Retis[1]. We
currently distribute it in COPR[2] because we can't easily follow the
Fedora Rust packing rules at the moment but that is far from being
perfect (on all levels). Don't get me wrong, I think the packaging rules
make sense; but those are a high entry barrier for projects with
multiple unpackaged complex dependencies (recursively).
We wrote a plan with detailed steps to get there,
https://github.com/retis-org/retis/milestone/13.
It's basically divided into the following directions:
- Take over / upgrade some outdated dependencies.
- Package the missing dependencies in Fedora. Some are easier than
others to package / maintain.
- Remove the use of other dependencies.
There are a few issues to overcome (packaging complex dependencies takes
time, I think we have a dep of a dep w/o a license, etc) but most
importantly I think the concern is with maintenance; especially when
it's not trivial.
All that of course will be quite an effort so we thought we should ask
for your input and advises on if this is the right direction or if you
have some comments? Also we're wondering if there's anything that could
ease the process or make the delay shorter (eg. vendoring *some* deps
temporarily)?
The above also raises an additional question: any additional dependency
added upstream, if not already packaged and non trivial, could gate
upcoming releases from being packaged. Gating upstream development on
downstream packaging doesn't look right and I guess those kind of issues
are just expected (we already have one coming); but wanted to ask just
in case :)
Thanks!
Antoine
[1] https://retis.readthedocs.io/en/stable/
[2] https://copr.fedorainfracloud.org/coprs/g/retis/retis/
Hi all,
TL;DR: I am planning to orphan rust-eza later today. Be warned - it's
a lot of work to keep up with upstream (~1 release per week), keeping
it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and
there are license shenanigans afoot since the v0.20.0 release (package
is currently at v0.19.3).
Given that I don't even use eza myself and just packaged it because it
was on some people's wishlist as the maintained fork of exa, I really
cannot justify the ongoing cost of maintaining this package to myself.
Fabio
---
Longer version:
The upstream project releases new versions at a very fast pace (almost
exactly one release per week on average this year). They also have set
up GitHub's dependabot to automatically and eagerly bump all their
Rust dependencies to the latest versions - most of which are not
technically necessary. Additionally, they often add new dependencies,
which is an additional maintenance burden on top of needing to keep up
with their eager dependency bumping.
The package should be in relatively good shape, except that it is
slightly outdated. I have just yesterday updated it to the latest
version that does not introduce new dependencies that aren't packaged
yet for Fedora (0.19.3, released on Sep 12). At the time of writing,
the latest release is 0.20.6 (released today, Oct 31) - but more info
on that below.
The package is available in all branches of Fedora, in EPEL 9, and in
EPEL 8. All branches are equivalent, with the exception of EPEL 8,
which needs special handling because the Rust packaging toolchain
there is ancient (from RHEL 8), while the EPEL 9 toolchain matches the
one in Fedora. The package was branched for EPEL 8 per a user's
request, so dropping it (or letting it become outdated) just a few
months after it was added to EPEL 8 would not be nice IMO.
It might be of note that the project was relicenced from MIT to
EUPL-1.2 without much fanfare as of the 0.20.0 release, in this
mess-of-a-PR: https://github.com/eza-community/eza/pull/1155 - I'm not
a lawyer, but the maintainer unilaterally slapping a different license
onto a project that's been around since 2017 in some form without
asking other contributors (or the original author of exa) doesn't pass
the smell test for me.
I'm working on building clamav for EPEL10. The versions of various rust
dependencies are different in EPEL10 than EPEL8/9. We generally try to
maintain identical spec files across the EPEL releases (and Fedora <=41
at this point). Would it be acceptable to do the following in the spec
file:
sed -i -e '/^base64 *=/s/= .*/= "0.*"/' Cargo.toml
sed -i -e '/^bindgen *=/s/= .*/= "0.*"/' Cargo.toml
sed -i -e '/^cbindgen .*=/s/= *".*"/= "0.*"/' Cargo.toml
sed -i -e '/^image .*=/s/= *".*"/= "0.*"/' Cargo.toml
sed -i -e '/^onenote_parser *=/s/= *.*/= "0.*"/' Cargo.toml
to allow for using whatever is the latest version of the dep in each
release?
Or is there some other preferred way to handle this situation?
Thanks,
Orion
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/