On Sun, Oct 20, 2019 at 15:20 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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@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
