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#L270 > [2] https://github.com/fedora-modularity/libmodulemd/issues/269 > [3] https://meetbot.fedoraproject.org/fedora-meeting-3/2019-04-23/modularity.2019-04-23-15.01.log.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
