• ticket had meeting keyword but is worded for furture meeting, FESCo
  to invite stakeholders to the FESCo meeting next week to discuss
  (dgilmore, 18:47:20)

Maybe I'm confused about the problems, but does it help at all to have dnf-plugin-system-upgrade first check the current running system actually being up to date before proceeding with the upgrade?

And then is it possible to "pre-flight" the upgrade, predicting what packages will or might get broken? Maybe that's a future feature.

On whether things might break vs definitely get removed, there's a long history of major OS upgrades breaking programs. It's annoying, but it's unsurprising, in a Captain Obvious way. Can anyone think of an example where programs are removed, even with a warning, during an OS upgrade, on any platform?

The reality is an "upgrade" is not expected to be anything like a factory reset, but a default where possibly broken packages get removed makes it something like a faux factory reset. Maybe such behavior is also a future feature the user could opt into.

OK, so just to roughly sum up the conversations being held elsewhere:
We need to account for all of the following cases (I will refer to Fedora N and Fedora N+1 as the originating and target releases):
1. Upgrade path is completely clean (uninteresting case)
1. One or more packages has a higher N-V-R on Fedora N than Fedora N+1.
1. The upgrade process to Fedora N+1 would result in a dependency conflict for one or more packages installed in Fedora N

== Lower N-V-R on upgrade ==
Options:
Upgrade process refuses to upgrade until the upgrade path is clean.
* The upgrade path may never be completely clean.
Upgrade process upgrades all packages that it can and leaves some packages from Fedora N in place until Fedora N+1's repositories update. (Current behavior)
* May introduce dependency conflicts (see below).
* Unexpected user experience.
* Results in only partially-upgraded system.
* Upgrade process distro-syncs all packages
* May cause some packages to downgrade (which may cause issues reading data files if they have changed format)
* May introduce dependency conflicts (see below).

== Dependency Conflicts on Upgrade ==
This is of particular concern to third-party repositories, but is not exclusive to them. Upgrades of all packages in the base repository may (read: '''will''') introduce conflicts between packages that depend on certain features/APIs.

Options:
Packages whose dependencies cannot be satisfied on Fedora N+1 will be identified to the user and the user must make a decision to remove them or abort the upgrade.
Packages whose dependencies cannot be satisfied on Fedora N+1 will be identified to the user and the user must make a decision to leave them on the system, possibly in a broken state until repository updates shake out the problems. This option is not currently possible in DNF and would require non-trivial engineering effort to accomplish.
* Both of the above options could be presented to the user, assuming both are available.

I'm intentionally not defining a mechanism for the above decisions.

My personal recommendation at this time would be for the following (assuming DNF and dnf-plugin-system upgrade maintainers commit to the necessary changes):
Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them all, leaving them in a possibly-broken state, or aborting.

If that option is not possible in time, I my secondary recommendation is to do all of the above except offering the option to leave the broken packages on the system.

If I have missed anything from the BZ discussion, please correct me in the comments.

I'm in general agreement with the proposal. I don't really like the option of leaving the system in a broken state and would prefer the "upgrade+remove OR don't upgrade" choices only, but I can see situations where a sufficiently knowledgeable user would want to leave them in place.

Yeah, the more I think about it, the more I agree with Josh. I'm revising my proposal as follows:

Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting.

In one simple implementation, this could be accomplished by having the default behavior of {{{dnf system-upgrade --releasever=FN+1}}} be to display the packages that have conflicts and a message saying "use the --force" argument to remove these packages during upgrade.

Also, when I say "by default" for distro-sync, I should be clear that I'm not requiring there to be an option to switch it off. Just that distro-sync must be the default behavior.

Replying to [comment:8 sgallagh]:

In one simple implementation, this could be accomplished by having the default behavior of {{{dnf system-upgrade --releasever=FN+1}}} be to display the packages that have conflicts and a message saying "use the --force" argument to remove these packages during upgrade.

If the decision is not interactive by default, many of the non-official guides and forum advice will end up recommending the stronger variant right away, sadly. There is definitely need for a non-interactive command version (something like {{{--assumeyes}}}, which is the same what you meant with {{{--force}}}, I think), but the default command should be interactive and not just say "run this again with --foo argument".

However, that's just a UI design pattern and might not be directly relevant to this proposal of a default upgrade mode. I'm writing this just because I didn't want this to end up as an official recommendation how to do it.

Replying to [comment:9 kparal]:

Replying to [comment:8 sgallagh]:

In one simple implementation, this could be accomplished by having the default behavior of {{{dnf system-upgrade --releasever=FN+1}}} be to display the packages that have conflicts and a message saying "use the --force" argument to remove these packages during upgrade.

If the decision is not interactive by default, many of the non-official guides and forum advice will end up recommending the stronger variant right away, sadly. There is definitely need for a non-interactive command version (something like {{{--assumeyes}}}, which is the same what you meant with {{{--force}}}, I think), but the default command should be interactive and not just say "run this again with --foo argument".

However, that's just a UI design pattern and might not be directly relevant to this proposal of a default upgrade mode. I'm writing this just because I didn't want this to end up as an official recommendation how to do it.

I proposed that as a simple implementation example because I realize that adding new UI interaction might be prohibitive in the remaining time for F23. If the DNF developers want to commit to having an interactive prompt there, I'm not compelled to argue.

(Also, I meant to say --assumeyes. You are correct.)

AGREED: "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting. " (+7,0,0) (nirik, 18:33:46)