On Mon, Nov 12, 2018 at 8:10 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?
To quote myself "once we get gating turned back on, it will enforce
that the package cannot go to stable."
I'd prefer to assume that anyone who knows to request a build-time dep
would be sufficiently informed about their package to also know if it
would need that as a runtime dep and wouldn't blindly submit it,
though.