Dne 23. 04. 19 v 18:14 Stephen Gallagher napsal(a):
It is not mentioned anywhere in the official packager documentation,
but the modulemd format for packages includes a default[1] for the
`ref:` attribute of RPM components. Essentially, if you leave the
`ref:` out of the YAML, the Module Build Service will interpret that
as a reference to the HEAD of the `master` branch in the git
repository.
Recently, Vit Ondruch raised a request[2] that we change this behavior
such that instead of matching `master`, it should instead reference
the HEAD of a branch of that component that matches a prefixed branch
of the module.
So, for example, if we were building the `nodejs:10` module stream, if we had:
```
data:
...
components:
nodejs:
rationale: Javascript runtime and npm package manager.
buildorder: 10
```
(lacking a `ref:`)
This would be interpreted as `ref: stream-nodejs-10` instead of `ref:
master`, as now.
And I also proposed fallback to master when no matching branch is found.
In today's Modularity Working Group Meeting[3], those present
generally agreed that this was a better approach and lends itself to a
better packager experience. We did not, however, come to an agreement
on how to transition to this new default.
When I was thinking about the migration, it always felt natural to me to
bump the module metadata version and treat the ref differently by the
version.
Vít
>
> There are two possible approaches we can take:
> 1) Allow MBS to look first for the branch of the component matching
> the module stream (`stream-nodejs-master`) and then fall back to
> 'master'.
> 2) Interrogate all of the modules in Fedora, migrate any components
> missing a `ref:` explicitly to be `ref: master`, then change MBS to
> treat the unset value as above.
>
> Arguments for 1) are that it won't break backwards-compatibility, but
> on the other hand it could lead to subtle misbehavior, such as if MBS
> did a shallow or otherwise incomplete `git clone` that misses the
> proper branch.
>
> Arguments for 2) are that it lends itself to hard failures, forcing
> packagers to correct their YAML documents, at the cost of some (as yet
> unspecced) initial effort.
>
>
> So I'm asking for opinions on which route we should take.
>
>
> [1]
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml...
> [2]
https://github.com/fedora-modularity/libmodulemd/issues/269
> [3]
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-04-23/modularity....