Implementing opt-in support for SPECPARTS in rust2rpm

[Fabio Valentini]

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

[the Mulhern]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to rust-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


-- 
"It is necessary to say plainly that all this ignorance is simply
covered by impudence. Statements are made so plainly and positively
that men have hardly the moral courage to pause upon them and find
that they are without support." - G. K. Chesterton, "The Everlasting
Man"

[Fabio Valentini]

On Wed, May 1, 2024 at 2:53 AM the Mulhern <amulhern(a)redhat.com&gt; 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

[Josh Stone]

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?

[Fabio Valentini]

On Wed, May 1, 2024 at 6:24 PM Josh Stone <jistone(a)redhat.com&gt; 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