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/
On Wed, Mar 6, 2024 at 5:58 PM Antoine Tenart atenart@redhat.com wrote:
Hello,
Hello!
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).
I agree, for packages with deep and / or broad dependency trees, this can be a bit of a burden ... but I still think that the benefits outweigh the costs here.
We wrote a plan with detailed steps to get there, https://github.com/retis-org/retis/milestone/13.
Looks good to me, though it appears that there are some misunderstandings about how our packaging process works.
For example, this issue is a complete non-issue: https://github.com/retis-org/retis/issues/353 retis is not published on crates.io and retis-derive is not published separately. So when building from the GitHub sources, there is no way (and no need) to either vendor (since it's already included!) or package separately (not published on crates.io).
It's basically divided into the following directions:
- Take over / upgrade some outdated dependencies.
Looking at the list, the packages you think are unmaintained are actually maintained, but we have projects in Fedora that depend on that old version. There is no need to "take them over", the packages are perfectly fine. If you need newer versions, we can look into updating them to newer versions while still providing the older versions for the things that currently need those.
- Package the missing dependencies in Fedora. Some are easier than others to package / maintain.
- Remove the use of other dependencies.
This is a great idea! Reducing the number of dependencies can be quite helpful, both in the short- and the long-term.
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.
This is true, but for the "library-only" part of the Rust stack, that maintenance is shared between multiple members of the Rust SIG. So you're not on your own with that.
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)?
"Partial vendoring" is not really possible with how cargo defines registries / registry replacements, as far as I know.
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 :)
This is something that you'll probably have to live with when you're part of a Linux distribution. Upstream projects adding new dependencies is *always* a problem for downstream consumers, no matter which programming language is used.
Fabio
Hello,
Quoting Fabio Valentini (2024-03-10 16:30:30)
On Wed, Mar 6, 2024 at 5:58 PM Antoine Tenart atenart@redhat.com wrote:
We wrote a plan with detailed steps to get there, https://github.com/retis-org/retis/milestone/13.
Looks good to me,
Thanks for having a look at it!
though it appears that there are some misunderstandings about how our packaging process works.
For example, this issue is a complete non-issue: https://github.com/retis-org/retis/issues/353 retis is not published on crates.io and retis-derive is not published separately. So when building from the GitHub sources, there is no way (and no need) to either vendor (since it's already included!) or package separately (not published on crates.io).
I probably got confused by `cargo publish --dry-run` some time ago, which told me retis-derive wasn't published; but that is completely unrelated. Good to know keeping retis-derive in the same repo is supported, w/o having to publish it.
It's basically divided into the following directions:
- Take over / upgrade some outdated dependencies.
Looking at the list, the packages you think are unmaintained are actually maintained, but we have projects in Fedora that depend on that old version. There is no need to "take them over", the packages are perfectly fine. If you need newer versions, we can look into updating them to newer versions while still providing the older versions for the things that currently need those.
Nice! I guess once needed we should just ask on the ml? (But let's fix our other issues first).
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.
This is true, but for the "library-only" part of the Rust stack, that maintenance is shared between multiple members of the Rust SIG. So you're not on your own with that.
So we have to do the initial packaging and then the maintenance load will be shared; nice :)
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)?
"Partial vendoring" is not really possible with how cargo defines registries / registry replacements, as far as I know.
All right.
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 :)
This is something that you'll probably have to live with when you're part of a Linux distribution. Upstream projects adding new dependencies is *always* a problem for downstream consumers, no matter which programming language is used.
Right, we came to that conclusion when discussing this in the project not long ago. Even if the upstream development and the packaging is done by the same people, it's really wearing a different hat.
Thanks for the pointers! Antoine
Reviving that thread to give you a small update, thanks to your recommendations and some modifications in our project we were finally able to start the official review process in https://bugzilla.redhat.com/show_bug.cgi?id=2295792.
Thanks! Antoine
Hello,
Quoting Antoine Tenart (2024-07-10 16:45:00)
Reviving that thread to give you a small update, thanks to your recommendations and some modifications in our project we were finally able to start the official review process in https://bugzilla.redhat.com/show_bug.cgi?id=2295792.
Things took some time (multiple levels of new deps) but it looks like we can finally start the last step: packaging Retis!
However we would need two existing packages to be updated[1]: - rust-bindgen to 0.70 - rust-libbpf-sys to 1.5
What the best way to tackle this: requesting this here? making a PR (not sure how but I can look this up)?
Also it looks like rust-bindgen is now at 0.71 upstream. Retis can be fixed to use this one if that's easier.o
[1] https://download.copr.fedorainfracloud.org/results/@retis/playground/fedora-...
Thanks! Antoine
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Hello,
Quoting Antoine Tenart (2024-07-10 16:45:00)
Reviving that thread to give you a small update, thanks to your recommendations and some modifications in our project we were finally able to start the official review process in https://bugzilla.redhat.com/show_bug.cgi?id=2295792.
Things took some time (multiple levels of new deps) but it looks like we can finally start the last step: packaging Retis!
Great!
However we would need two existing packages to be updated[1]:
- rust-bindgen to 0.70
- rust-libbpf-sys to 1.5
What the best way to tackle this: requesting this here? making a PR (not sure how but I can look this up)?
Not everybody reads this mailing list - it's often better to comment on the bugs for those missing updates and / or mark them as blocking for what you're working on.
In this case, unless Retis needs features that were added in bindgen v0.70, I think it should work to just relax the dependency to ">=0.69,<0.71" for now.
For libbpf-sys, I would ask Michel Lind (salimma) - he's been handling the recent updates, and they've always been a bit tricky.
Also it looks like rust-bindgen is now at 0.71 upstream. Retis can be fixed to use this one if that's easier.o
I don't think that's necessary. But you could relax the dependency to ">=0.69,<0.72" (if that works!) to be future-proof ;)
Fabio
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Quoting Antoine Tenart (2024-07-10 16:45:00)
However we would need two existing packages to be updated[1]:
- rust-bindgen to 0.70
- rust-libbpf-sys to 1.5
What the best way to tackle this: requesting this here? making a PR (not sure how but I can look this up)?
Not everybody reads this mailing list - it's often better to comment on the bugs for those missing updates and / or mark them as blocking for what you're working on.
So adding issues on bz right? That I can do :)
In this case, unless Retis needs features that were added in bindgen v0.70, I think it should work to just relax the dependency to ">=0.69,<0.71" for now.
That would work. Is that acceptable to patch the project as part of the rpm building steps or should this be upstreamed? I would prefer the former as this is a distribution limitation, but checking.
For libbpf-sys, I would ask Michel Lind (salimma) - he's been handling the recent updates, and they've always been a bit tricky.
OK, will do (or as part of a bz issue).
Thanks! Antoine
On Fri, Dec 20, 2024 at 2:14 PM Antoine Tenart atenart@redhat.com wrote:
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Quoting Antoine Tenart (2024-07-10 16:45:00)
However we would need two existing packages to be updated[1]:
- rust-bindgen to 0.70
- rust-libbpf-sys to 1.5
What the best way to tackle this: requesting this here? making a PR (not sure how but I can look this up)?
Not everybody reads this mailing list - it's often better to comment on the bugs for those missing updates and / or mark them as blocking for what you're working on.
So adding issues on bz right? That I can do :)
They already exist:
- https://bugzilla.redhat.com/show_bug.cgi?id=2305397 - https://bugzilla.redhat.com/show_bug.cgi?id=2260404
All outstanding version updates for Rust crates in Fedora should have an associated ticket in bugzilla.
In this case, unless Retis needs features that were added in bindgen v0.70, I think it should work to just relax the dependency to ">=0.69,<0.71" for now.
That would work. Is that acceptable to patch the project as part of the rpm building steps or should this be upstreamed? I would prefer the former as this is a distribution limitation, but checking.
Sure, this is fine as a downstream-only change.
Fabio
Quoting Fabio Valentini via Rust (2024-12-20 17:41:10)
On Fri, Dec 20, 2024 at 2:14 PM Antoine Tenart atenart@redhat.com wrote:
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
Not everybody reads this mailing list - it's often better to comment on the bugs for those missing updates and / or mark them as blocking for what you're working on.
So adding issues on bz right? That I can do :)
They already exist:
- https://bugzilla.redhat.com/show_bug.cgi?id=2305397
- https://bugzilla.redhat.com/show_bug.cgi?id=2260404
All outstanding version updates for Rust crates in Fedora should have an associated ticket in bugzilla.
Ah, nice!
In this case, unless Retis needs features that were added in bindgen v0.70, I think it should work to just relax the dependency to ">=0.69,<0.71" for now.
That would work. Is that acceptable to patch the project as part of the rpm building steps or should this be upstreamed? I would prefer the former as this is a distribution limitation, but checking.
Sure, this is fine as a downstream-only change.
All right.
Thanks! Antoine
On Fri, Dec 20, 2024 at 2:14 PM Antoine Tenart atenart@redhat.com wrote:
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Quoting Antoine Tenart (2024-07-10 16:45:00)
However we would need two existing packages to be updated[1]:
...
- rust-libbpf-sys to 1.5
...
For libbpf-sys, I would ask Michel Lind (salimma) - he's been handling the recent updates, and they've always been a bit tricky.
OK, will do (or as part of a bz issue).
I did open a PR 2 weeks ago[1] as well as commented on the release tracker on bz[2] (and made it a blocker for the Retis one) and even sent a direct email to Michel. But I haven't heard anything so far so I'm wondering what else I can do to unblock things. Any advice?
Thanks! Antoine
[1] https://src.fedoraproject.org/rpms/rust-libbpf-sys/pull-request/1 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2260404#c7
On Fri, Jan 24, 2025 at 10:38 AM Antoine Tenart atenart@redhat.com wrote:
On Fri, Dec 20, 2024 at 2:14 PM Antoine Tenart atenart@redhat.com wrote:
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Quoting Antoine Tenart (2024-07-10 16:45:00)
However we would need two existing packages to be updated[1]:
...
- rust-libbpf-sys to 1.5
...
For libbpf-sys, I would ask Michel Lind (salimma) - he's been handling the recent updates, and they've always been a bit tricky.
OK, will do (or as part of a bz issue).
I did open a PR 2 weeks ago[1] as well as commented on the release tracker on bz[2] (and made it a blocker for the Retis one) and even sent a direct email to Michel. But I haven't heard anything so far so I'm wondering what else I can do to unblock things. Any advice?
Probably got lost in the pile, Michel was on holiday until just a few days ago. I'll ping him on Matrix.
Fabio
On Fri, Jan 24, 2025 at 5:27 PM Fabio Valentini via Rust rust@lists.fedoraproject.org wrote:
On Fri, Jan 24, 2025 at 10:38 AM Antoine Tenart atenart@redhat.com wrote:
On Fri, Dec 20, 2024 at 2:14 PM Antoine Tenart atenart@redhat.com wrote:
Quoting Fabio Valentini via Rust (2024-12-20 12:30:06)
On Fri, Dec 20, 2024 at 11:11 AM Antoine Tenart via Rust rust@lists.fedoraproject.org wrote:
Quoting Antoine Tenart (2024-07-10 16:45:00)
However we would need two existing packages to be updated[1]:
...
- rust-libbpf-sys to 1.5
...
For libbpf-sys, I would ask Michel Lind (salimma) - he's been handling the recent updates, and they've always been a bit tricky.
OK, will do (or as part of a bz issue).
I did open a PR 2 weeks ago[1] as well as commented on the release tracker on bz[2] (and made it a blocker for the Retis one) and even sent a direct email to Michel. But I haven't heard anything so far so I'm wondering what else I can do to unblock things. Any advice?
Probably got lost in the pile, Michel was on holiday until just a few days ago. I'll ping him on Matrix.
Thanks!