On Fri, Jun 21, 2019 at 1:28 PM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
> Hello,
>
> I just wanted to give you an update from my last discussions on
> #fedora-modularity and other places.
>
> # Problems definition
>
> * Default modules can't have conflicting dependenices
> * Changing dependencies in a stream is not supported
>
> # Why does libgit2 has to be a module?
>
> libgit2 is not just one package. It is an ecosystem.
>
> Right now libgit2 module provides libgit2 itself and python bindings.
> While we can obviously provide libgit2_0.26, libgit2_0.27 and such,
> this does not help us with python packages. Nobody in sane mind will rename them
> and make them conflict (because they are not parallel-installable).
>
> I wanted to also add ruby bindings to a module, but I never got time
> to actually do it.
>
> # What about dependencies change?
>
> Let's not lock ourselves into libgit2 story, just take an abstract names.
>
> Module foo:rolling depends on bar:1. Name of stream "rolling" means to serve
> purpose of "user-focused content meant for general use". That means,
> if foo's upstream decided to update their bar dependency to a new version,
> foo:rolling maintainer would just switch dependency to bar:2.
AIUI, the issue here is that *there should not be* bar:1 and bar:2.
Module streams are supposed to be 'functional' (as in your 'rolling'
example). They are not supposed to be version numbers. This needs to be
more clearly explained in the guidelines and enforced, but the way the
modularity concept turned out, version-based module streams are *wrong*
and should not exist. I recall earlier designs along the way actually
sort of envisaged version-based module streams, but that is not how
it's supposed to work in the final design.Versioned module streams should definitely exist, that's one of the main points of Modularity. But there are certainly exceptions.To keep the expectations of Fedora's stable ABI within a release, we can't change the default stream of a module mind-release. I know, that's probably clear and that's not the issue here. But building on that, at the same time, we can't let "dnf update" to change streams on your system mid-release, because that would be basically breaking the ABI expectations as well — different mechanics, same problem.So in this specific example — where upstream is changing the ABI very often — freezing that package to one major version per Fedora release doesn't work. Especially when different packages need a different version at the same time. So streams are probably not the right way to deal with this specific case. Streams are a great way to provide our users a choice. A choice of one of multiple versions of software (mostly leaf applications) that are natively built and maintained for their fedora release (as opposed to enabling rawhide repos and I don't know what to get a different version). But it's not a solution for providing multiple versions of libraries that need to be installed at the same time.When different packages require different version of a library at the same time, we can definitely use existing mechanisms for parallel installation such as providing different packages with different names, installing the library into different places, like compat-packages.What Modularity could help you with — in an arbitrary case when there is bar:1 and bar:2 — is to build your "rolling" module (and other modules) against both of those using stream expansion, providing two different binaries of the same module stream (with different context), and letting DNF to install the right one based on what is on your system, or based on defaults. This is one of the new capabilities Modularity brings to the table. Of course, that only works if your "rolling" module can be actually built against both.But for cases when your "rolling" module can't be built against both versions, existing mechanisms for parallel installation should be used instead. Modularity doesn't reimplement those existing mechanisms.
To be fair, I don't think our docs say this in this form anywhere. There are probably hints that could draw the potential reader to this conclusion, but we probably need to be more explicit than that — by providing specific guidance for some model cases, demonstrating where Modularity can help (and how) and where it can't. I (or anyone) should probably fix that!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--Senior Software Engineer
Adam Šamalík
---------------------------
Red Hat
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
