How to handle upgrades to Fedora 21

[Stephen Gallagher]

On Wed, 2014-10-01 at 16:28 -0400, Stephen Gallagher wrote:
> 
> 
> 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.



Yet one more change. A number of folks from the Workstation, Server and
fedup teams got together in #fedora-workstation today and hashed out a
new plan. We decided that it was fine to modify fedup and that it was
also acceptable to force the user to make a choice at upgrade time.

To that end, fedup will grow a new mandatory option: --product. It will
take one of four arguments: "standard" (non-productized), "server",
"workstation" or cloud.

For each of the Products, fedup will inject the appropriate set of
packages necessary to make the resulting system contain a superset of
the packages that one would get with a default installation of the
selected Product. (In a technical sense, it would essentially be
injecting "@^$PRODUCT-product-environment" onto the yum installation
command to ensure that all of those packages are part of the
transaction).

I have sent an email to the QA folks to get this arrangement added to
the Beta Criteria, since that's our last chance to realistically test
upgrades before release. So fixing this becomes a blocker to Beta.
-------------- 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/20141003/0665c32c/attachment.sig>