On Mon, Nov 12, 2018 at 9:02 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > 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? > It is not. Arguably, this check should be blocking across the board. I personally would rather have this check earlier than Bodhi (mark builds in Koji as failed if they aren't installable), but that appears to be a thing we can't do. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
