On Mon, Nov 12, 2018 at 9:02 AM Vít Ondruch <vondruch(a)redhat.com> 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(a)redhat.com> 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(a)chello.at>
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!