10:58 a.m.
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/
10:30 a.m.
On Wed, Mar 6, 2024 at 5:58 PM Antoine Tenart <atenart(a)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
8:58 a.m.
Hello,
Quoting Fabio Valentini (2024-03-10 16:30:30)
On Wed, Mar 6, 2024 at 5:58 PM Antoine Tenart
<atenart(a)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
79
days inactive
86
days old
2 comments
2 participants
participants (2)
-
Antoine Tenart -
Fabio Valentini