Learn more about these different git repos.
Other Git URLs
It is hard to differentiate api and non-api packages provided by a module.
When users install package via dnf install <name>, they can install a package provided by a default stream without realizing that the packages is actually modular. Thus the expectations are that the package is properly supported on Fedora and can be used to build custom applications or as a standalone app.
dnf install <name>
For non-api packages this is not the case, as module owner doesn't provide full support for them and can update them with incompatible changes as long as module API still works.
Therefore, we propose a policy that all packages exposed through the default stream must belong to the module API.
If the policy is accepted, it should probably be implemented as a check in fedmod lint.
We talked about this at Flock, and because there is some confusion about what exactly it means for packages to be in the module API, let's rephrase this:
"All packages in a default module stream must be, in terms of maintenance level and stability, treated the same way as non-modular packages."
That's to follow one the principles I believe we have: Putting packages in a default module stream should not change the way they can be used in terms of installation and updates.
Just for the record, I'm +1 to that policy change proposal.
We talked about this at Flock, and because there is some confusion about what exactly it means for packages to be in the module API, let's rephrase this: "All packages in a default module stream must be, in terms of maintenance level and stability, treated the same way as non-modular packages." That's to follow one the principles I believe we have: Putting packages in a default module stream should not change the way they can be used in terms of installation and updates. Just for the record, I'm +1 to that policy change proposal.
Minor adjustment: "All packages exposed in a default module stream must be, in terms of maintenance level and stability, treated the same way as non-modular packages." Mostly just to clarify that if the package is filtered out with the data.filter.rpms section (meaning it's a build-time-only dependency and doesn't appear in the repo) it doesn't need to follow this rule.
data.filter.rpms
@sgallagh Yes, good point!
Metadata Update from @psabata: - Issue tagged with: Meeting
At the weekly meeting, we agreed on:
"Default modules should declare all their exposed packages as API or bundle appropriately; alternatively they must stop being the default; the exact wording will be figured out in the ticket later"
Metadata Update from @asamalik: - Issue untagged with: Meeting - Issue tagged with: needs-docs
A pull request with the policy change https://pagure.io/fedora-docs/modularity/pull-request/100.
@churchyard, do you know who maintains policies for packaging modules in Fedora https://docs.fedoraproject.org/en-US/modularity/policies/?
I thought that the document is maintained by an official body, e.g. FPC, with a similar rigorousness as Packaging guidelines for RPM packages are maintained. But it seems that module polices are in hands of anybody who can write to a general modularity documentation at https://pagure.io/fedora-docs/modularity/.
Can I freely edit it, or do I need acknowledgment of FESCo or FPC?
I don't think there is a maintainer of this (either a person or a body). The last change that I am aware of was done via the change process and approved by FESCo.
You are correct that whoever can edit the document can in fact technically change it, but I don't think that was the intention. My understanding is that this is not a packaging policy and hence has nothing to do with FPC (FPC was never consulted on modularity at all). I think you need FESCo approval, but if the changes are radical (e.g. allowing modular-only packages or default streams), using the change process is probably the most transparent option.
Log in to comment on this ticket.