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
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
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
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
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.