Bug 1650286
| Summary: | RFE: Add a new header field and macros for modularity tags | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Šabata <psabata> | |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> | |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | rawhide | CC: | carlwgeorge, ffesti, igor.raits, imcleod, mjw, ngompa13, packaging-team-maint, pmatilai, pmoravco, sgallagh, vmukhame | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | rpm-4.14.2.1-4.fc30 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1650287 (view as bug list) | Environment: | ||
| Last Closed: | 2018-12-19 13:48:50 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1650287 | |||
|
Description
Petr Šabata
2018-11-15 18:09:26 UTC
Remind me, why can't we use provides? (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. 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. 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. 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. ModularBuild sounds excellent for the purpose. Great, let's go with that! > NSVC
What is this? I get name:stream-version, but what's "C"?
(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. 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. Can we get an ETA on this? 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. Clear needinfo |