On Fri, Jun 21, 2019 at 1:28 PM Adam Samalik <asama...@redhat.com> wrote:
> > > On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson < > adamw...@fedoraproject.org> 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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org >> > > > -- > > Adam Šamalík > --------------------------- > Senior Software Engineer > Red Hat > -- Adam Šamalík --------------------------- Senior Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
