#109 Allow RPM builds for one _stream_ from different dist-git branches per %fedora version
Opened 5 years ago by praiskup. Modified 2 years ago

That said, it would be very convenient to define that some module builds:

components:
  rpms:
    first-package:
      rationale: Provides the core functionality.
      refs:
        fedora-28,fedora-29: 3.0-28  # special-case F{28,29}
        default: 3.0

Instead of:

components:
  rpms:
    first-package:
      rationale: Provides the core functionality.
      ref: 3.0 # everything build from one branch

The thing is that the package layouts can be really very different across
Fedora major versions; but we are forced to build the very same spec file
for each Fedora version from the same git refspec. That leads to ugly
conditions like '%if 0%{?fedora} > X' which really complicates both the
spec file maintenance and the overall readability. More, different people
can be responsible for different fedora versions.

Concrete example: PostgreSQL module ships 9.6 stream ATM. But it was
created against package-set provided by Fedora N, where N <= 30. In F30
though we provide different set of subpackages in 'postgresql.spec', and
we do some modularity changes that are not worth backporting to F29-. So,
it would be nice to have one branch (say 'stream-9.6') as the default
branch (for modular builds in f30+), and say ('stream-9.6-fc29') for the
older spec file layout.


While I would still propose putting everything in one SPEC with lots of ugly macros around it (considering we're trying to get away from release-style branching overall), if we implement something like this, I would prefer just branching the modulemd, I think.

For instance, you could be building from modules/postgresql:9.6-f28 for F28 and standard 9.6 for everything else. The former would need to define stream in the modulemd and have specific module-level dependencies, as would the other (excluding f28).

@psabata

I would prefer just branching the modulemd, I think.

As far as I understand it, I'd say this would be even more flexible.

@psabata

I would prefer just branching the modulemd, I think.

Do I get it right that this is not yet possible?

@psabata

I would prefer just branching the modulemd, I think.

Do I get it right that this is not yet possible?

It's not. MBS uses the branch name to determine the stream. While MBS lets you set your own stream in modulemd, in Fedora this is currently restricted by policy (or should be).

Metadata Update from @asamalik:
- Issue tagged with: needs-design

4 years ago

Do I understand it correctly that you don't like conditions in spec files, but because you need the conditions somewhere, you want to add them into modulemd file? So instead of having one place for ugliness, we will have two of them? [End of sarcasm.]

While two years later it's still not supported, I have two proposals:

(1) Persuade FESCo to lift the ban from overriding stream values as explained by @psabata. I think you liked that approach. I think that a motivation for the ban is that a module stream is always built from the same sources. The banned override, as well as your proposal, violates the motivation. So I wouldn't have high hopes.

(2) If you can bear platform-specific streams, e.g. postgresql-impl:9.6-f28 in Fedora 28 and postgresql-impl:9.6-else everywhere else, then there is a way available right now:

Build postgresql-impl:9.6-f28 for Fedora 28 and postgresql-impl:9.6-else for all other Fedoras, each with a different postgresql component ref. Then build a wrapping, end-user facing module postgresql:9.6 like this:

dependencies:
  - requires:
    platform: [f28]
    postgresql-impl: [9.6-f28]
  - requires:
    platform: [-f28]
    postgresql-impl: [9.6-else]

(Technical note: [-f28] notation is not properly supported in MBS, and you would have to replace it with a complement like [f29, f30, f31].)

It reminds me virtual provides in RPM world. You leave resolving the condition for compose/DNF. I admit it's not appealing.

(3) Last option is swallow the bitter pill and create, and maintain a dedicated branch (e.g. "9.6") in rpms/postgresql repository only for the purpose of the module, and have all the ugly macros in the spec file. Fedora calls these branches non-release and they are allowed exactly for the purpose of modules.

Login to comment on this ticket.

Metadata