On Sun, Oct 20, 2019 at 15:20 Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl>
wrote:

> On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote:
> > Alternate Proposal:
> >
> > Most things from the original proposal in the first message of this
> > thread remains the same except:
> >
> > Module stream metadata would gain two new optional attributes,
> > "upgrades:" and "obsoletes:".
>
> I'm sorry, but I'm against this proposal, both in its first form, and
> as amended here. The long discussion in this thread has pushed me over
> into conviction that modules should not be "on by default" in any way
> in Fedora.
>
> The first form of the proposal was already staggeringly complex —
> "default", "dep_enabled", "default_enabled", "default", …. Recording
> user intent when the users interacts directly with the thing
> might be OK, but mapping that intent onto dependencies that are pulled
> in automatically is not something that can be well defined. My expectation
> is that we'd forever be fighting broken expectations and unexpected cases.
>
> But the amended proposal actually makes things *worse*, even more complex.
> We would have two parallel sets of dependency specifications: on the
> rpms level and on the module level. The interactions between them would
> be hard to understand for users.
>
> I also don't think we need this at all: everything that could be
> expressed using deps between modules can also be expressed using deps
> between rpms. We have a rich and well defined dependency language for
> rpms, so let's just use it.
>
> One of the operational problems with Modularity is that it places huge
> expectations on dnf. Modularity was never very well defined, and dnf
> had to adapt on the fly to changing rules and requirements. This never
> went well. Even more complexity, with three parallel sets of
> semi-interacting-semi-independent sets of constraint rules (rpm deps,
> module intent, module obsoletes+provides), expressed in different form,
> is imho a recipe for bad ux.
>
> At the same time, this thread has shown that this additional
> complexity would need to be added to have upgrade paths for modules.
> Essentially, to me this thread has shown that Modularity needs to go
> back to drawing board, to reassess goals and assumptions and
> implementation choices. A lot of what people *thought* Modularity
> would give them, is simply not possible, and at the same time, the
> costs and impact on the rest of the distribution is higher than
> expected.
>
> As has been extensively discussed, modules are opaque and a) by design
> make some rpms not visible and not as available to other packagers as
> before, b) make it harder for people outside of Fedora to reuse our
> packaging and build on top of Fedora.
>
> Modules also raise the complexity of packaging. I understand that for
> some expert packagers they provide new functionality, but they complicate
> life for the majority of packagers. I think this additional complexity
> is of the reasons for the decline in participation of non-expert
> packagers in Fedora that was show in FPL's graphs.
>
> The work that went into Modularity is certainly not all wasted: I think
> we all understand the problem and what solutions don't work much better
> then before. I think we should take a step back and try for a solution
> which has lower end-user complexity and better backwards compatibility.
>
> I'm not asking for an improved proposal here: for me, Modularity in its
> current form is simply not a net benefit for Fedora's packagers or users.
> Thus, I'm against both default modules, and adding modules in the
> buildroot, and against rebasing any part of Fedora to build on top of
> modules. This is "contingency mode", i.e. thinking how to bring things
> back to working state. I think it is OK to allow modules to be available,
> but they must be opt-in, and normal rpms may not allow on the
> modularized rpms in any way.
>
> I wrote this in reply to this thread, even though some things might
> fit more in the sister thread "Fedora 32 System-Wide Change proposal:
> Modules in Non-Modular Buildroot". I don't want to send two mails with
> a lot of text, and the two things are inextricably linked: we cannot
> enable modules by default, or make more things depend on them by
> including in the build root, without having working upgrade paths.
>

If I were to start from scratch on this, I would look at the simplest
solution I would want from Boltron. I want to make it so a package team can
make a set of packages in a repository and work out how I can interact with
other repositories. I also want to easily build that package set in ways to
work on different versions of an operating system.  Let us ignore the early
goal of modularity of ‘I don’t want a ton of repositories’ which led to
‘virtual repositories’ which led to ‘modules’. For our ‘persona’ story..
let us go back to the days of Dag and Athimm .. and we want to be able to
give them the tools to build 2 repositories which worked on Fedora. The
tool set they have currently is that they just drop everything in a pool or
into tiny 1 package repositories and the user has to figure out what they
want.

You couldn’t compare their version of imapd and clamav and they have no way
to communicate whether their versions work together or not. The usual story
was ‘well just integrate those into the downstream OS’ but that becomes
trickier with certain groups of packages which may have multiple
capabilities but can only do one or the other (this could be a container..
but again we have to make it so you can build said container with its
different options).

What if we made a set of tools which allowed them to group together the
items into their repository and build out a set of artifacts which could
say ‘yes you can use my NodeJS to supplement your Node stuff.. but python38
was compiled with experimental puppy and wont work with your python38
stuff.’ From an RPM level this is hard to do because you are either writing
out a large number of spec files with a dozen compat names to say
‘compat-python38-works-with-athimm-foobar-3.4.0-1.dag.noarch.rpm’ and
‘compat-python38-breaks-with-athimm-foobar-3.4.0-1.dag.noarch.rpm’. The
user may not want to deal with such long names they just want to be able to
have ‘dnf’ try to add a repository and know if it will work with other
items.

While some of that would seem to be extra repository meta-data, we also
want to make it easy so that Dag, Athimm and Joe-At-Home to factory build
their set of packages together knowing it will work either with Dag, not
work with Dag, etc etc. And we want to make it easy for them to build
against say Fedora N-2,N-1,N,N+1, rawhide (as would be the case right now
before FN+1 gets released) without having to do too much work.

Again some of this may need to be done with packaging rules, but we want to
make it easy for the builder to put those in place without a lot of work
from either a packager or user. Anyway I think the above may be a good way
to restart the conversation. Let us try to aim the solution at packagers

1. They have a lot of packages they need to tie together
2. They need to build those packages for multiple deliverable operating
environments
3. They need to interact with other groups of packages in a way which that
their group can 'know' if there is a chance of coworking.
4. Many are tied to systems which have fast, hard update cycles which do
not work with even a 'fast' OS like Fedora.

Users are wanting
1. A system which can tie these different speed things together.
2. That system to be updated or is clear on why it can't and what needs to
be done.


>
_______________________________________________
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

Reply via email to