This is related to #6658 but is different.
Through discussions with @puiterwijk in and audit of the MBS code, we are trying to reduce the permissions required by the module-build-service, so that it poses less of a risk.
In order to do that (for mbs#333) we need a new tag created that has the full package list for Fedora, but which should not inherit from an existing Fedora tag.
Let's call the new tag module-package-list (which describes precisely what it is for).
module-package-list
Current, MBS runs with admin permissions. When it tags builds into tags that it has created, it does so with force=True which automatically adds the package to the package list of the tag first, before tagging the build.
force=True
We want to remove force=True because it is too heavy handed.
We could dynamically add packages to the package list of the new module tag every time a new build comes along, but that requires elevated permissions.
Instead, if we have a master tag with a full package list of every package in Fedora, and if our new modules tags inherit from that tag, then we don't have to worry about the package list or have any special rights to manipulate it (good).
If we made this new tag inherit from the rawhide tag, then it would automatically get the nice package list that we need.
However, we need to ensure that the new tag does not accidentally provide any BuildRequires which are not explicitly specified by the module being built. If a BuildRequires is absent, we want the build to fail to ensure modules are really isolated from one another.
BuildRequires
Therefore, we need this new tag to not inherit from any other tags.
Once created, we will need to patch this script to automatically populate the package list of this new tag, while not contributing any builds.
@ralph Few questions that needs to be answered:
Thanks! Good questions.
How long are you planning on using this tag?
Roughly, forever.
Are you going to merge the builds later into any other tag?
No.
If its based on release, can we name it after the release like f26-module-package-list?
Unfortunately, it is not based on release. (Modules are supposed to be release independent until they are composed into a release later). The same build of a module might be composed into two different releases some day (at least, that's part of the goal).
If its not based on release, whats the future for this tag? Just testing purposes?
We need it to stick around indefinitely with no builds in it, but with a full package list, so that tags which inherit from it can inherit the package list.
New tag "module-package-list" is added:
$ koji add-tag module-package-list
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
This needs careful consideration, as I suspect it will break our blocking model. lets leave it open and discuss at the meeting
Metadata Update from @ausil: - Issue status updated to: Open (was: Closed) - Issue tagged with: meeting
:+1: I'll try to be there. Is there any info on the blocking model you can point me at ahead of time?
@ralph is this still a required feature?
Please advise and update if there have been changes.
Modularity is now working in F28. Closing this ticket.
Metadata Update from @syeghiay: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)