Dne 12. 11. 18 v 13:43 Stephen Gallagher napsal(a): > On Mon, Nov 12, 2018 at 4:50 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: >> >> Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a): >>> On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: >>>> Raphael Groner wrote: >>>> >>>>> Kevin, >>>>>> * that no package may ever be module-only, but >>>>>> modules can only be used for non-default >>>>>> versions. >>>>> That statement doesn't make any sense for me. Can you explain, please? How >>>>> should modules live without packages in background? We'd already discussed >>>>> this in another thread. >>>> I don't think you understood the sentence I wrote. >>>> >>>> The current state is that we can have: >>>> main repo: no package foo, no package libfoo (but many other packages) >>>> module foo-1: foo-1.8.10, libfoo-1.8.12 >>>> module foo-2: foo-2.0.0, libfoo-2.0.1 >>>> but the "main repo: no package foo, no package libfoo" part is what I am >>>> objecting to, especially if libfoo is used by more packages than just foo. >>>> >>>> I want to require the main repo to contain some version of libfoo, and other >>>> packages (from the main repo or from modules other than foo) should be >>>> required to use the version in the main repo and not in some non-default >>>> module. >>> This is literally the exact way things work today, except that instead >>> of "the main repo", we treat it as "the main repo OR the default >>> stream of the module". >>> >>> Nothing in the main repo is permitted to use anything that is not >>> available in the main repo or a default module stream at runtime. Full >>> stop. >>> >>> The case of Ursa Major is special: it's addressing the case where we >>> may have some *build-time* requirements that are not in the default >>> repo. >> >> I might be missing something, but how do you want to enforce this ^^? >> This sounds that although build succeeds, runtime might fail later, >> because of missing dependencies. This might not happen for Go you used >> as an example, because it is statically linked, but it must be the case >> for other dynamically linked libraries. >> > Well, it *should* be enforced in Bodhi This rather important detail is not mentioned anywhere (at least quick grep for 'bodhi' and 'dep' over the two tickets from initial email did not revealed anything). > with the dependency-check test > (dist.rpmdeplint). It should see that the packages won't be > installable and once we get gating turned back on, it will enforce > that the package cannot go to stable. The dependency check is not blocking ATM, is it? V. _______________________________________________ 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
