How to handle upgrades to Fedora 21

[Stephen Gallagher]

On Wed, 2014-09-24 at 12:16 -0400, Stephen Gallagher wrote:
> There has been some discussion in various forums lately about how we
> will handle fedup upgrades from Fedora 20 to Fedora 21 products.
> 
> Several suggestions have been made that warrant discussion:
> 
>  1) Upgrades from Fedora 20 remain non-productized. They pick up
> fedora-release-standard and upgrade only their existing packages.


I've had a number of conversations with the yum/dnf and fedup people
over the last week. The tl;dr version: option 1) is the only realistic
option.

So, a bit more contributing detail:

First, the Products have both a minimal set and a default set of
functionality that they want to have exposed if that Product is
installed. What we've decided that this means is that, barring explicit
influence, anyone who is installing Fedora Workstation or Fedora Server
should be getting the default set of functionality and can later (or in
a kickstart file) trim it back.

Without changing the fedup package in Fedora, we could do upgrades to
each of the Products or non-productized versions by providing on F20 a
do-nothing fedora-release-[standard|cloud|server|workstation] file that
in F21 has explicit requirements on any of the packages necessary to
reach the minimal set of functionality. We can't force it to the default
set (without allowing RPM soft dependencies, which is not currently
supported or well-tested in Fedora), so upgrading through this path
wouldn't guarantee the preferred result state (particularly for
Workstation, which wants to have a certain set of common applications
installed by default). Furthermore, it makes the upgrade process more
complicated because it would require the user to manually install
'fedora-release-standard' in order to get the non-productized experience
and they would not be able to upgrade *at all* without selecting one of
them.

Fedora officially only supports upgrades from a *fully-upgraded Fedora*
to the next version, so we could work around this by adding a temporary
explicit Requires: fedora-release-standard on the F20 fedora-release
package, thereby forcing all upgrades to be non-productized. This is my
recommended approach as it requires only a single change (the added
Requires:) to fedora-release to make it work. The end-result of this
upgrade is a system that is just a newer version of whatever DIY set of
packages the previously-F20 system was running.

It's also possible that we could rig up a selectable approach by
creating a full set of empty fedora-release-* packages and arranging it
so that fedora-release-standard satisfied the upgrade requirement if it
wasn't specified, but this requires us to make sure that the automatic
dependency-resolution for all of yum, dnf, gnome-software, yumex and
apper all selects the correct default. I know for a fact that at least
yum and dnf follow different resolution patterns, so while it could be
possible, it would be a nasty hack relying on internal knowledge of the
tools. That seems somewhat fragile to me, but it could be done if we
strongly want it.

The thing to note is that in all scenarios, the user *MUST* fully update
their F20 system first, or the results will be undefined and could be
unpleasant. We need to spell this out very clearly to our upgrading
users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141001/106148e3/attachment.sig>