On Mon, Oct 7, 2019 at 11:33 AM Jaroslav Mracek <jmracek@xxxxxxxxxx> 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 packages) > Fail safe data will persist forever > Please provide more information here, because I don't see where you're coming from. > 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" as its 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 "Module B" 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 predict offhand. > 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 tools). > 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 less critical. > > 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 user's system. > 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". _______________________________________________ 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
