On Mon, Oct 7, 2019 at 11:33 AM Jaroslav Mracek <jmracek(a)redhat.com> wrote:
I would like to open discussions more widely, because we are talking about future of
software distribution and discussing only particular issue is not an approach how to
delivery solid and stable architecture.
What issues I have in mind?
Your list of issues lacks sufficient context.
1. Fedora system upgrade (libgit2, axa, bat)
In this case, are we talking about F30->F31 where the default stream
changes or also considering when the dependencies need to change?
2. Adding new stream into distribution
- will result in an error
Uhh, why? Maybe there are some missing words here indicating under
what conditions adding a stream to the distro would cause problems?
3. Removal of stream from distribution
- dependent module on removed stream will creates modular dependency error
Assuming we only allow this to happen at the release boundary, I think
this is desirable behavior. If someone has locked themselves to a
stream, we should disallow upgrades of the platform if the new
platform cannot support that stream.
4. Changing stream dependency
- dependency issue
I try to address that in my design proposal.
5. Removal of module from distribution (replaced by non-modular
Fail safe data will persist forever
Please provide more information here, because I don't see where you're
6. Upgrade path between contexts
This will help with modular dependency resolution
Can you state the problem more thoroughly? I *think* what you're asking is this:
"Module A" can function with either "http:2.4" or "http:2.6"
dependency. "Module B" can only function with "http:2.6" as a
dependency. Installing Module A results in DNF selecting "http:2.4" to
resolve the transaction. Later, the user wants to install "Module B":
How should DNF proceed?
There are two possible routes we could take:
1) Dependency error when trying to install "Module B". Optionally
provide aid to the user that they might be able to manually switch
streams from "http:2.4" to "http:2.6" before attempting to install
2) Automatically perform an "upgrade" step where all software
installed from "http:2.4" is replaced by content from "http:2.6" as
part of the transaction. This is probably the more user-friendly
approach, but it may have some subtle complexities in the
dependency-resolution (dealing with nested dependencies) that I can't
7. Upgrade path between module streams
So far this is not described or part of the design
This actually is part of the design. Or, rather, it is explicitly not
specified. The idea was that we would deal with upgrade path between
module streams on a case-by-case basis, since not all streams actually
can transition between them. For the proposal of following the default
streams, we'd need to ensure that rules are in place that such streams
need to behave similarly to how they would have in non-modular Fedora
(meaning a clean upgrade path, possibly with automatic migration
8. Module switching
At the present time this is completely disabled for stability reasons
Acknowledged. See above.
9. Changing defaults o redesign of defaults
- defaults have the same behavior like enabled modules. Only problems with defaults are
Some of requirements are in conflict. Like user must be not able to switch a stream by
accident but stream must be changed automatically in other example.
Resolving each of this points have consequences in behavior on other parts of modularity
and rpm environment therefore any change must be planned well.
Yes, which is why I consulted with user experience designers before
proposing the approach in the original post. It's difficult to strike
a balance between "keeping the user safe" and "keeping the user
happy". We decided that the only reasonable line we could draw was
"did the user ask for this directly or did they just take what was
handed to them".
Some issues could be resolved by additional data in metadata like
obsoletes, information about substreams. Others by changing implementation in dnf/libdnf.
The last important part is represented by packaging restrictions, guidelines (people must
know limitation of technology).
Obsoletes are something we may want to consider, but I think they
should follow whatever behavior we settle on for tracking changes in
the default stream. Meaning: they should only be allowed for cases
where an upgrade can be performed safely/automatically or a special
case like fedora-obsolete-packages to forcibly remove things from the
Lets also ask question what we can change for Fedora 31, 32, or 33?
I assume this actually means "Let's figure out what schedule to
deliver these things on".