[PATCH] Move captive portal to fedora-release-workstation

Stephen Gallagher sgallagh at redhat.com
Mon Oct 6 12:21:52 UTC 2014




On Fri, 2014-10-03 at 21:18 +0200, drago01 wrote:
> On Fri, Oct 3, 2014 at 9:01 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> >
> >
> >
> > On Fri, 2014-10-03 at 20:45 +0200, drago01 wrote:
> >> On Fri, Oct 3, 2014 at 8:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
> >> >> On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
> >> >> > On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
> >> >> > > On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
> >> >> > > > On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
> >> >> > > > > On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
> >> >> > > > > > > I don't really like that people that do upgrades get a worse
> >> >> > > > > > > experience because of that pointless change but well ...
> >> >> > > > > >
> >> >> > > > > > There's nothing that says a user doing an upgrade wants to upgrade to
> >> >> > > > > > Workstation.  There's also nothing that is going to magically upgrade
> >> >> > > > > > them to Workstation anyway.  Also, they don't have this in F20 so
> >> >> > > > > > their experience is not worse, it's the same.
> >> >> > > > >
> >> >> > > > > I think fedup needs to to require specification of the product when
> >> >> > > > > upgrading from Fedora 20:
> >> >> > > > > [...]
> >> >> > > >
> >> >> > > > I've been trying to work with the packaging folks and the fedup
> >> >> > > > maintainer, but right now it's looking infeasible to do a
> >> >> > > > non-productized (F20) upgrade to a Productized F21. People who want
> >> >> > > > Workstation are going to have to do a clean install. People upgrading
> >> >> > > > from F20 will end up with non-productized F21 (equivalent
> >> >> > > >  to a Spin).
> >> >> > >
> >> >> > > In the Fedora Workstation PRD we have:
> >> >> > >
> >> >> > >  Robust Upgrades
> >> >> > >
> >> >> > >  Upgrading the system multiple times through the upgrade process should
> >> >> > >  give a result that is the same as an original install of Fedora
> >> >> > >  Workstation. Upgrade should be a safe and process that never leaves the
> >> >> > >  system needing manual intervention.
> >> >> > >
> >> >> > > This refers, of course, to upgrades between versions of Fedora
> >> >> > > Workstation, but I think we're sending a strong message in the wrong
> >> >> > > direction if we make it require a complex manual procedure to upgrade
> >> >> > > from F20 to F21 Workstation.
> >> >> > >
> >> >> >
> >> >> > Well, the procedure isn't necessarily *complex*, but it *is* necessarily
> >> >> > manual. Please see my email on devel@, I talked about the actual
> >> >> > technical issues that are getting in the way here (and the fact that
> >> >> > we're dangerously close to Beta for trying to land entirely new code in
> >> >> > fedup...)
> >> >>
> >> >> There's three separate things here:
> >> >>
> >> >>  * We need to make it almost impossible to *accidentally* upgrade to
> >> >>    non-productized F21 and think you are getting the Workstation
> >> >>    experience.
> >> >>
> >> >
> >> > I think this is the wrong way of thinking about this. As noted elsewhere
> >> > in this or the other thread, we *cannot* make the assumption that
> >> > someone upgrading from F20 actually *wants* it to be Fedora Workstation,
> >> > even if they happen to have the GNOME desktop installed.
> >> >
> >> > There are plenty of people who are using a system installed from one of
> >> > the spins as well as people who are using Fedora as a server (possibly
> >> > headless) and having the upgrade process result in Workstation except
> >> > when *explicitly* chosen is not acceptable.
> >> >
> >> >
> >> >>  * We need to provide a feasible way to upgrade from F20
> >> >>    Fedora 21 Workstation.
> >> >>
> >> >
> >> > I would certainly be in favor of having this. The definition of
> >> > "feasible" is very complicated, though. This can be solved, but it's
> >> > debatable if it can be solved sensibly in the remaining time. (See the
> >> > explanations in the other thread).
> >>
> >> Why from the chatlog you attached elsewhere one would conclude that
> >> the "yum install fedora-relase-foo && fedup" would work. Or what did I
> >> miss?
> >
> > You missed the part where that approach takes away the no-manual-steps
> > part of it. If we go that path, then you MUST explicitly do 'yum install
> > fedora-release-[standard|workstation|cloud|server]' before you can run
> > fedup.
> >
> > If people feel that this is an acceptable approach, we can investigate
> > it, but the general sense I was getting is that "fedup --network 21"
> > should work on its own with no other interaction.
> 
> Well "fedup --network 21" could simply check if any of those packages
> is present and if not print a message. Shouldn't this be that big of a
> change.


Just a bit of an update; the new upgrade plan should be able to resolve
this issue without the patch (and also in a way that is likely
acceptable to all groups).

We can remove the explicit Requires: NM-captive-portal-fedora from both
gnome-shell and fedora-release workstation, because the new 'fedup
--network 21 --product=workstation' command will automatically install
it as long as it's part of the @^workstation-product-environment group
in comps (which a quick inspection shows is not currently the case but
is a two-line change that I will submit right now).

Of course, this approach has the same issue as this patch does, which is
that it will only ensure that this new package is added to the
Workstation upgrades and not to standard upgrades...

Another option would be to take advantage of the new 'Recommends:'
dependencies in RPM, but there are two issues with this:
1) I don't know if yum/fedup supports this yet
2) We'd need to ask FPC/FESCo for a special exemption to allow this,
since weak dependencies are currently not permitted in Fedora.

If we get this, then we can simply have 'Recommends:
NM-captive-portal-fedora' as a dependency of gnome-shell and then it
will be installed on all upgrades using gnome-shell, with the option to
later remove it if someone has a real desire to do so.

I'll ask the yum and fedup folks whether this is feasible.
-------------- 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/desktop/attachments/20141006/b996bcae/attachment.sig>


More information about the desktop mailing list