Re: Modularity component ref: behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 23, 2019 at 12:50 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>
> 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.
>
>
> 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.
>
> 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.

Option 2.  It's more painful upfront for a small (I think?) number of
people, but with the learning curve around modularity I would MUCH
rather go for explicit behavior everywhere we can.  Too much implicit
behavior that the packager doesn't know about creates confusion and
surprise down the road.

josh
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux