Re: Ursa Major (modules in buildroot) enablement

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

 



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