Hello Rust packagers,
I have realized today that with the upcoming EOL of Fedora 38, all branches of Fedora will ship with a version of RPM (i.e. >= 4.19) that supports dynamic generation of spec file snippets at build-time (SPECPARTS).
In particular, if I understand correctly how it works, I think this functionality would be great for generating the "+feature-devel" subpackages in Rust crate packages. It would reduce spec file churn when updating Rust crates to new versions, and would make it easier to integrate tooling like packit:
There would no longer need to be a MUST requirement to regenerate spec files for Rust crates for every new upstream version, since that requirement is almost entirely caused by the requirement of keeping feature subpackages in sync with crate features.
Since this functionality would not be available in EPEL 9 probably ever, if this is implemented, it would probably be best kept as an opt-in feature for now (likely via rust2rpm config) for Fedora-only Rust packages.
What do you think?
Fabio
Hi!
I do not know anything about the implementation of SPECPARTS. That being said:
I think the general idea that you seem to be proposing would be an unusually good use for this SPECPARTS.
In general, I believe that packagers are wary of stuff that they can't look at or debug being part of the spec file. I would be wary of SPECPARTS for that reason, always.
But this proposal seems like something that could be made very regular and more or less invisible to the user. Also, the explanation for it would be simple, something like generate sub-packages for the powerset of crate features (or whatever is actually done).
As you say, it would make upstream Rust projects' integration with packit for packaging tests pretty easy, certainly easier than it must be now.
And that's really all I've got.
- mulhern
On Tue, Apr 30, 2024 at 4:46 PM Fabio Valentini decathorpe@gmail.com wrote:
Hello Rust packagers,
I have realized today that with the upcoming EOL of Fedora 38, all branches of Fedora will ship with a version of RPM (i.e. >= 4.19) that supports dynamic generation of spec file snippets at build-time (SPECPARTS).
In particular, if I understand correctly how it works, I think this functionality would be great for generating the "+feature-devel" subpackages in Rust crate packages. It would reduce spec file churn when updating Rust crates to new versions, and would make it easier to integrate tooling like packit:
There would no longer need to be a MUST requirement to regenerate spec files for Rust crates for every new upstream version, since that requirement is almost entirely caused by the requirement of keeping feature subpackages in sync with crate features.
Since this functionality would not be available in EPEL 9 probably ever, if this is implemented, it would probably be best kept as an opt-in feature for now (likely via rust2rpm config) for Fedora-only Rust packages.
What do you think?
Fabio
Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/rust@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, May 1, 2024 at 2:53 AM the Mulhern amulhern@redhat.com wrote:
Hi!
I do not know anything about the implementation of SPECPARTS. That being said:
I think the general idea that you seem to be proposing would be an unusually good use for this SPECPARTS.
In general, I believe that packagers are wary of stuff that they can't look at or debug being part of the spec file. I would be wary of SPECPARTS for that reason, always.
I agree, something that feels like "too magical" is usually not good for debugging ... In this case, I think it would be fine, though: The subpackages that are generated by rust2rpm for crate features are 100% boilerplate in almost all cases.
And in the cases where they are not 100% boilerplate, the only thing different is additional Requires that can be configured via rust2rpm.toml (like for "-sys" bindings that have different features for different API levels of the wrapped C library). I'm not yet sure how that use case will be supported, but that's a special case that should be OK to deal with *after* shipping an initial, working implementation that deals with most cases.
But this proposal seems like something that could be made very regular and more or less invisible to the user. Also, the explanation for it would be simple, something like generate sub-packages for the powerset of crate features (or whatever is actually done).
For every crate feature (including the implicit "default" feature), exactly one subpackage is generated by rust2rpm (except for those "hidden" via rust2rpm.toml config).
As you say, it would make upstream Rust projects' integration with packit for packaging tests pretty easy, certainly easier than it must be now.
And that's really all I've got.
Thank you for your feedback!
Fabio
On 4/30/24 1:45 PM, Fabio Valentini wrote:
Since this functionality would not be available in EPEL 9 probably ever, if this is implemented, it would probably be best kept as an opt-in feature for now (likely via rust2rpm config) for Fedora-only Rust packages.
If a currently-Fedora-only package gets requested for EPEL, either as a leaf package or a newly-needed dependency, are you going to be willing to revert / opt-out again? Or would you rather diverge in EPEL?
On Wed, May 1, 2024 at 6:24 PM Josh Stone jistone@redhat.com wrote:
On 4/30/24 1:45 PM, Fabio Valentini wrote:
Since this functionality would not be available in EPEL 9 probably ever, if this is implemented, it would probably be best kept as an opt-in feature for now (likely via rust2rpm config) for Fedora-only Rust packages.
If a currently-Fedora-only package gets requested for EPEL, either as a leaf package or a newly-needed dependency, are you going to be willing to revert / opt-out again? Or would you rather diverge in EPEL?
In my experience, diverging branches are really painful to deal with, so in that case I would rather make the package opt out again (which should usually just be one "rust2rpm" command away).
Fabio
-
Fabio Valentini -
Josh Stone -
the Mulhern