On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson <adamwill(a)fedoraproject.org>
On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
> 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
> 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
> purpose of "user-focused content meant for general use". That means,
> if foo's upstream decided to update their bar dependency to a new
> 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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Senior Software Engineer