Bug 1650286 - RFE: Add a new header field and macros for modularity tags
Summary: RFE: Add a new header field and macros for modularity tags
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1650287
TreeView+ depends on / blocked
 
Reported: 2018-11-15 18:09 UTC by Petr Šabata
Modified: 2019-11-21 09:53 UTC (History)
11 users (show)

Fixed In Version: rpm-4.14.2.1-4.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1650287 (view as bug list)
Environment:
Last Closed: 2018-12-19 13:48:50 UTC


Attachments (Terms of Use)

Description Petr Šabata 2018-11-15 18:09:26 UTC
We currently label modular RPM builds by filling the DistTag header field.  However, it turns out this field isn't entirely unused:

https://pagure.io/modularity/issue/113
https://github.com/rpm-software-management/rpm/issues/589

Therefore we would like to add a new field for our purposes, ensuring we don't run into similar conflicts in the future.  We use this as a bool to tell modular and non-modular builds apart when the repodata isn't available but we also use it to store the original module NSVC for accountaing purposes.

I think ModuleTag would be a reasonable name for this.

Please, also ensure we can set this field for both binary and source RPM builds, preferrably via %{moduletag}.  We also need to be able to query this.

Comment 1 Igor Gnatenko 2018-11-15 18:26:18 UTC
Remind me, why can't we use provides?

Comment 2 Stephen Gallagher 2018-11-15 18:33:22 UTC
(In reply to Igor Gnatenko from comment #1)
> Remind me, why can't we use provides?

Short answer: we can't set Provides on the SRPM creation or for subpackages that contain zero files (metapackages), because the automatic dependency generators don't run.

Comment 3 Petr Šabata 2018-11-15 18:40:19 UTC
That's one thing that could be fixed.  However, since we'll want RPM to work with this information later, a header field makes more sense.  We also have no need for this in the repodata and don't want to pollute the provides for no real reason.

Comment 4 Panu Matilainen 2018-11-16 08:10:12 UTC
Please come up with a more specific name, "module" is such a generic and widely used term. For example "modularity", "modular" or "modulemd" (append Tag if you like) would help point towards the Modularity effort rather than the generic concept of modules which are everywhere, including but not limited to kernel.

Comment 5 Petr Šabata 2018-11-16 09:22:34 UTC
Ah, thought you were against just the word "module" on its own.

Considering your suggestion, would ModularBuild make sense to you?  It kinda feels like a bool and since we store the build NSVC in there, it could work.

Comment 6 Panu Matilainen 2018-11-16 09:23:29 UTC
ModularBuild sounds excellent for the purpose.

Comment 7 Petr Šabata 2018-11-16 09:45:43 UTC
Great, let's go with that!

Comment 8 Neal Gompa 2018-11-19 19:58:33 UTC
> NSVC

What is this? I get name:stream-version, but what's "C"?

Comment 9 Stephen Gallagher 2018-11-19 20:12:54 UTC
(In reply to Neal Gompa from comment #8)
> > NSVC
> 
> What is this? I get name:stream-version, but what's "C"?

C is "context". It's a disambiguation between two module streams that are the same except for their dependencies. (For example, let's say I build a webapp that is compatible with either Node.js 8.x or 10.x. We'd build two versions of webapp:stream, one for 8.x and one for 10.x and differentiate them with 'context'. Then, e.g if there were other module streams on the system that could only use nodejs:8, DNF would select the context of the webapp:stream that works with that version of nodejs.

Comment 10 Petr Šabata 2018-11-20 09:35:18 UTC
Yes, mostly true.  Although it's not strictly about runtime dependencies, it's about distinguishing builds built in different buildroots (different platforms, different combinations of modular deps) -- this might or might not affect the runtime deps, but it usually does.

Comment 11 Petr Šabata 2018-11-21 18:29:18 UTC
Can we get an ETA on this?

Comment 12 Panu Matilainen 2018-12-19 13:48:50 UTC
Almost forgot the Fedora side of this, but waken up by the disttag-discussion on fedora-devel:

the upstreamed modularitylabel tag backported to Fedora as of rpm-4.14.2.1-4.fc30.

Comment 13 Florian Festi 2019-11-21 09:53:41 UTC
Clear needinfo


Note You need to log in before you can comment on or make changes to this bug.