Learn more about these different git repos.
Other Git URLs
Currently, if you want to add a completely private build dependency to a module, you need to do the following:
This is error prone, since it means that build-only dependencies get shipped by default (as only the first step is needed for a passing build), and even if you do explicitly filter out all the RPMs from that SRPM, if one of your build dependencies starts defining a new RPM, you'll end up shipping that until you adjust your module's filters.
One possible way to address that would be to define a new kind of component: build-rpms. These would be essentially the same as rpms, except that all the RPMs they define would be automatically added to filters.rpms, excluding them from the published repo.
build-rpms
rpms
filters.rpms
@ralph @langdon I'd be interested to hear your thoughts on this. Prompted by the fact that https://src.fedoraproject.org/modules/python3-ecosystem/blob/master/f/python3-ecosystem.yaml is currently following the model where compoments included specifically as build dependencies for custodia are being shipped as part of the module, and that doesn't seem like the right approach to me.
@ncoghlan I think that this seems like a really sensible enhancement, but I am not sure I'd call it a new component; maybe it would be easier to just make it an attribute of an existing component. So you would have something like:
components: rpms: # PyYAML-3.12-8.fc28 PyYAML: rationale: >- Autogenerated by Host & Platform tooling. ref: 60bf96a9c58d2402d682f51573425c86a8d6d530 buildonly: 1
My rationale for having it as a separate component type was to make it easier to tell the difference at a glance (similar to the way requires and buildrequires are separate lists in the dependencies section).
requires
buildrequires
dependencies
A separate component category also means that the default buildorder could be different - since regular RPM components default to build order zero, build components might default to -1.
-1
That said, I do agree that a buildonly flag would work.
buildonly
Based on the discussion in #45, I think another option that would work here would be to offer a filters.srpms section, whereby listing an SRPM name there caused the SRPM to be omitted from the generated source repo, and all of the binary RPMs built from that SRPM to be omitted from the binary repo.
filters.srpms
(Allowing the SRPM to be omitted without also omitting the binary RPMs wouldn't cover the private build dependency case, and could also inadvertently lead to copyleft license compliance concerns)
@crobinso has posted a related enhancement to fedmod: https://pagure.io/modularity/fedmod/pull-request/61#
fedmod
That's a new fedmod rpms-from-srpm command to find out which RPMs an SRPM defines, allowing explicit filters to be generated more easily.
fedmod rpms-from-srpm
Login to comment on this ticket.