#1 [RFC] Add devel and feature subpackage generation and testing aparatus
Closed by decathorpe. Opened by gotmax23.
fedora-rust/ gotmax23/rust-packaging subpackages  into  main

Download 1.patch

Add devel and feature subpackage generation

%cargo_feature_subpackage

Simplest invocation:

%cargo_feature_subpackage default

Explicitly specify the crate name instead of using %{crate}:

%cargo_feature_subpackage default -n foo

Add extra preamble from a macro:

%global py39preamble %{expand:
Requires: python3-devel >= 3.9
Provides: useless-provides-to-show-that-multi-lines-work}
%cargo_extras_subpackage abi3-py39 -p %{quote:%py39preamble}

Add extra preamble inline:

%cargo_extras_subpackage abi3-py39 -p %{quote:Requires: python3-devel >= 3.9}

Add extra multiline preamble inline:

%{cargo_extras_subpackage abi3-py39 -p %{quote:
Requires: python3-devel >= 3.9
Provides: useless-provides-to-show-that-multi-lines-work
}}

%cargo_devel_subpackage

Simplest invocation:

%cargo_devel_subpackage
%license %{crate_instdir}/LICENSE
%doc %{crate_instdir}/README.md

Extra preamble and overriding the crate name work the same way.

Note that this doesn't use the new dynamic subpackage generation feature, so it's compatible with older rpm versions. It would be possible to get a list of features from cargo2rpm during %build and then generate dynamic definitions there without having to manually keep track of %cargo_feature_subpackage invocations.

Interesting. I wanted to work on something like this.

How is this supposed to work in rust2rpm?

Also, I don't particularly like the need to define extra macros and / or using %extend and %quote macros just to add additional Requires ... would it be possible to just add an -r foo flag for specifying additional Requires? We don't need support for any other RPM tags, so making this generic is not necessary.

For example, using something like this would be 100% enough for everything we do in Fedora:

%cargo_feature_subpackage default -r "pkgconfig(curl)"

Interesting. I wanted to work on something like this.

I hope I didn't step on your toes :).

How is this supposed to work in rust2rpm?

Not much differently. Replace the full subpackage definitions with calls to these macros.

would it be possible to just add an -r foo flag for specifying additional Requires?

Yes, but you wouldn't be able to specify if multiple times. You'd still need %{quote:...} if the dependency spec has a space. I think it makes sense to add -r in addition to -p.

Another thought: it would be possible to add a %cargo_feature_subpackages macro that accepts a multi-item list of features but no -p or -r and uses a lua for loop to call %cargo_feature_subpackage for each one.

I hope I didn't step on your toes :).

Not at all!

would it be possible to just add an -r foo flag for specifying additional Requires?

Yes, but you wouldn't be able to specify if multiple times. You'd still need %{quote:...} if the dependency spec has a space. I think it makes sense to add -r in addition to -p.

That's unfortunate ...

So something like this can't work even if the argument for the -r flag is quoted?

%cargo_feature_subpackage default -r "pkgconfig(curl) >= 7.88.1"

Another thought: it would be possible to add a %cargo_feature_subpackages macro that accepts a multi-item list of features but no -p or -r and uses a lua for loop to call %cargo_feature_subpackage for each one.

That's probably a step too far. I'd rather wait with fully automating this once the subpackage generation is available across all Fedora releases. And even then, RHEL 9 RPM will probably be too old for it forever ...

That's unfortunate ...

So something like this can't work even if the argument for the -r flag is quoted?

%cargo_feature_subpackage default -r "pkgconfig(curl) >= 7.88.1"

Yeah, you need to use %{quote:}. It's not like shell. The double quotes are just parsed as normal characters. With your example, the literal value of %{-r*} is "pkgconfig(curl) and the value of %{*} (positional args) is default >= 7.88.1".

Oh that's just awful. Aren't there two different argparse implementations in RPM? Are they both broken like that?

That's probably a step too far. I'd rather wait with fully automating this once the subpackage generation is available across all Fedora releases.

I agree.

And even then, RHEL 9 RPM will probably be too old for it forever ...

It might be possible to backport.

Aren't there two different argparse implementations in RPM? Are they both broken like that?

I don't think so? This is how rpm macros' getopt style parsing works. Unless you want to parse all the arguments yourself (%{**} contains the unprocessed argv)...

Alternatively, the macro could take the name of a macro (e.g. -r preamble) and then look that up %{preamble} without the need for %{quote}.

rebased onto 00006717ae27a4da0e40aed8e24753dd7a8866f2

I merged part of this PR as https://pagure.io/fedora-rust/rust-packaging/c/ae4453066d89a49dc5b8d4a9612790a00ba5c295?branch=main , and added test cases for most RPM macros. It should make making changes in the future easier. Thanks!

Cool! I submitted a follow up with two fixes to the tests: https://pagure.io/fedora-rust/rust-packaging/pull-request/17

Thanks! :)

I'm going to shelve this for now. The testing infrastructure has been very helpful though. :100:

Pull-Request has been closed by decathorpe

Metadata