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

[Stephen Gallagher]

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

> If the initial version of Fedora Workstation was a huge technical change
> involving different packaging systems, different filesystems, and so
> forth, I could see that we might want to require a fresh install a
> single time with a promise that things would be better in the future -
> but this really isn't the case.
> 

Well, to a lesser extent, this *is* a new packaging system; we're asking
for the capability to install a different set of packages based on which
Product you *might* want to upgrade to.


> > I need to follow up on the original devel thread about this.
> > 
> > Basically, the fedup maintainers don't want to spend effort on a
> > one-time upgrade feature, particularly with so little time before
> > release.
> 
> If https://github.com/wgwoods/fedup is the right upstream repository for
> fedup, it doesn't look like it has gotten much work this cycle -
> presumably because priorities are on different projects. How can the
> Fedora Workstation WG lend a hand?

We can have another conversation with Will. I'm attaching a log of the
last exchange so that we don't have to repeat all of it again.


-------------- next part --------------

(11:45:36 AM) sgallagh: .whoowns fedup
(11:45:36 AM) zodbot: sgallagh: wwoods
(11:45:40 AM) sgallagh: wwoods: Ping :)
(11:46:39 AM) sgallagh: wwoods: Have you been following the upgrade discussion I started yesterday on the devel@ list? I want to get your input as to how feasible the proposals are.
(11:47:47 AM) elad661: sgallagh: regarding that thread, imo the easiest way would be to make upgrades non productized and document in the wiki that you need to install fedora-release-whatever after the upgrade
(11:48:20 AM) sgallagh: elad661: Right, that would be my approach 1) as listed in the original message :)
(11:48:47 AM) sgallagh: But it would also be Really Nice (TM) if fedup could allow us to move onto a Product as well
(11:52:13 AM) mclasen_: sgallagh: its always the Really Nice (TM) stuff that gets you in the end...
(11:52:43 AM) sgallagh: mclasen_: Well, in this particular case, I *hope* it wouldn't be too difficult.
(11:52:59 AM) sgallagh: It's essentially just asking fedup to add a few extra packages to the transaction
(11:53:47 AM) mclasen_: I know, how hard can it be... and then we spend weeks debugging all the combinations of option X, Y, Z
(11:56:31 AM) talcite: Alright, got it on koji. So the error is at the bottom of the build log http://koji.fedoraproject.org/koji/taskinfo?taskID=7693520
(11:56:41 AM) sgallagh: mclasen_: This is why I'm asking wwoods for his input
(11:56:57 AM) sgallagh: If the answer is "This is going to be too much risk", then we punt.
(02:21:52 PM) wwoods: sgallagh: nope, I don't read devel@ normally, did you CC me?
(02:22:24 PM) wwoods: ah there it is - jreznik sent it to me
(02:24:12 PM) sgallagh: wwoods: How difficult would it be to implement option 3) from that email? Basically, I see it as adding a --product=<name> flag which forces certain packages (like fedora-release-$PRODUCT) to end up on the upgraded system
(02:24:27 PM) sgallagh: Rather than just the upgradded repoclosure of the current packages on the system.
(02:25:20 PM) wwoods: to be super-pedantic, you're asking two questions here: a technical question and a policy question
(02:25:35 PM) wwoods: so. technically: not hard at all
(02:26:27 PM) wwoods: I thought I had a TODO item for adding a mechanism to allow you to inject extra stuff into the transaction
(02:26:42 PM) wwoods: can't remember if I implemented that or not
(02:28:18 PM) wwoods: but yeah basically you'd just add it to the list of things to download and put the RPM name in package.list
(02:28:21 PM) wwoods: and off it goes
(02:29:38 PM) sgallagh: wwoods: And the policy question?
(02:29:40 PM) wwoods: as for *policy*: what's the default behavior? what happens if the user doesn't specify a --product? what happens if you're doing F21->F22 and you ask for a different product?
(02:29:49 PM) mclasen is now known as mclasen_
(02:30:11 PM) wwoods: is there a list of valid products for a given release? how does fedup find that?
(02:30:26 PM) wwoods: can fedup validate the given product name or do we just have to assume the user knows what they're doing?
(02:30:27 PM) sgallagh: wwoods: If they don't specify a product, for F21 we need to add fedora-release-standard and then operate as we have in the past after that
(02:31:00 PM) wwoods: then why not just add a fedora-release-standard package that is required by f20 fedora-release
(02:31:10 PM) wwoods: then fedup doesn't need any code changes whatsoever
(02:31:17 PM) wwoods: why add Special Rules?
(02:31:37 PM) sgallagh: fedora-release-standard conflicts with fedora-release-server, fedora-release-workstation and fedora-release-cloud
(02:32:17 PM) sgallagh: wwoods: Making the F20 fedora-release behave that way would be a simple way to implement option 1) from the email I sent.
(02:32:28 PM) sgallagh: (In other words, all upgraded systems remain non-productized)
(02:32:46 PM) adamw: sgallagh: i am *way* behind on devel but please remember to consider the netinst situation in this too, if it's not already happening. we have a whole thing to resolve with hte repos from that point of view as well.
(02:33:16 PM) sgallagh: adamw: How does netinst have anything to do with upgrades from F20?
(02:33:24 PM) adamw: sgallagh: it has something to do with the repo packages
(02:33:38 PM) adamw: the whole issue with getting the netinst to behave in product-ized fashion is based around the repos
(02:33:52 PM) sgallagh: There are no separate repo packages in the installed system
(02:34:08 PM) wwoods: but so far this is just a packaging problem - the next release has four providers for a new requirement, and you need some way of deciding which one gets installed if the user doesn't request one specifically
(02:34:12 PM) sgallagh: fedora-release-$PRODUCT exists solely so that packages that have different per-product default configurations pick up the right onw
(02:34:39 PM) sgallagh: wwoods: If the user doesn't request one specifically, they stay non-productized.
(02:34:40 PM) adamw: sgallagh: oh, sorry, i forgot we've split release- and repos-, carry on, though there may still be some overlap as there are requirements
(02:34:43 PM) sgallagh: That much we've all agreed on
(02:35:01 PM) sgallagh: adamw: sure, no problem. I understand where you were coming from :)
(02:35:11 PM) wwoods: sgallagh: okay, so can you convert between products at upgrade time? say F21->F22? sounds like no?
(02:35:18 PM) sgallagh: No
(02:35:25 PM) sgallagh: That's something we won't support
(02:35:30 PM) wwoods: so --product XXX would only be useful for F20->F21 upgrades?
(02:35:35 PM) sgallagh: yes
(02:36:05 PM) wwoods: and the user could, instead, just 'yum install fedora-release-{product}' before the upgrade
(02:36:09 PM) wwoods: and the Right Thing would happen?
(02:37:01 PM) elad661: before the upgrade? I'm not sure
(02:37:02 PM) sgallagh: fedora-release-$PRODUCT doesn't actually exist on F20
(02:37:17 PM) wwoods: yes, but it could
(02:37:21 PM) sgallagh: But that's an interesting thought... we might be able to just create some meta-packages there.
(02:37:23 PM) sgallagh: Good point.
(02:37:30 PM) sgallagh: That had not occurred to me
(02:37:57 PM) sgallagh: Though that approach has one flaw
(02:38:31 PM) sgallagh: That would mean that users would *have* to install one of fedora-release-[standard|workstation|cloud|server] before upgrades.
(02:38:42 PM) wwoods: heck, you can even add a little script to fedora-release that does "case $1 in; standard|server|workstation|cloud) yum -y install fedora-release-$1 ;; esac"
(02:39:05 PM) fenrus02: dont they all Provide:fedora-release=21 ?
(02:39:09 PM) sgallagh: wwoods: They can't coexist...
(02:40:47 PM) wwoods: ...I know? the point was to have a shortcut so you can do "fedora-choose-product server" on F20 and it'll install the server metapackage (which wouldn't conflict with F20 fedora-release, obvy)
(02:41:27 PM) wwoods: then you run your upgrade and you get f21 server. I assume f21 fedora-release-* obsoletes the old fedora-release package?
(02:42:02 PM) sgallagh: wwoods: Sorry, I misparsed that snippet
(02:42:20 PM) wwoods: yeah 'case', not 'for'
(02:42:23 PM) sgallagh: No, actually. You get both fedora-release and fedora-release-$PRODUCT
(02:42:24 PM) wwoods: sorry, I do way too much bash
(02:42:30 PM) wwoods: then that's even easier
(02:43:24 PM) sgallagh: Well, like I said, except for the fedora-release-standard case
(02:43:28 PM) sgallagh: Something has to pre-install that
(02:43:38 PM) wwoods: just make empty fedora-release-$PRODUCT packages for f20. this is a one-time, opt-in requirement so I don't see a huge problem with "if you want to choose a product, run this before the upgrade, otherwise you get default"
(02:44:17 PM) sgallagh: wwoods: You're missing the part where this doesn't solve "otherwise you get default".
(02:44:21 PM) sgallagh: That's what I've been trying to say
(02:44:32 PM) wwoods: I thought that was agreed-upon, though
(02:44:34 PM) fenrus02: you mean that an updgrade wouldnt simply upgrade whatever you have currently installed wwoods ?
(02:44:53 PM) sgallagh: wwoods: What do you mean agreed-upon?
(02:45:03 PM) wwoods: < sgallagh> wwoods: If the user doesn't request one specifically, they stay non-productized.
(02:45:06 PM) wwoods: < sgallagh> That much we've all agreed on
(02:45:20 PM) sgallagh: wwoods: Yes, we've agreed upon the desired outcome.
(02:45:30 PM) sgallagh: We haven't engineered a way for that to happen without additional steps :)
(02:46:41 PM) sgallagh: In the model you've described, in order to remain non-productized, a user has to run 'yum install fedora-release-standard' prior to fedup.
(02:47:18 PM) sgallagh: If they don't do that, complex RPM dep resolution will give them one of the four during upgrade. I think it'll be cloud just because it's first in the alphabet
(02:48:01 PM) wwoods: right. this is a standard multiple-providers packaging problem
(02:49:30 PM) sgallagh: Which would be solvable in fedup by checking if the system currently has a "Provides: fedora-release-product" installed on it somewhere and if not forcibly adds fedora-release-standard to the transaction
(02:49:43 PM) wwoods: it's solvable with a compare_providers plugin
(02:50:39 PM) sgallagh: go on
(02:51:10 PM) jwb: sgallagh, lmacken: that copr kernel should be done building in 30-45min i would think. make sure you install/update the kernel _after_ you install/update the rest (so that the initramfs is built with the new dracut and includes the new microcode)
(02:51:41 PM) sgallagh: jwb: How are we going to handle that in a regular update?
(02:53:02 PM) wwoods: I really don't want fedup to be permanently responsible for special depsolving rules that nobody will remember why they exist in a year
(02:53:03 PM) wwoods: anyway: http://yum.baseurl.org/wiki/CompareProviders
(02:53:10 PM) sgallagh: wwoods: ok
(02:53:41 PM) wwoods: (n.b. how the "shortest name tiebreaker" code was inherited from anaconda - adding special rules to one depsolver makes things weird)
(02:53:57 PM) sgallagh: wwoods: Is there documentation on how to write a compare_provider?
(02:54:03 PM) jwb: sgallagh, i'll figure out the requires for it. i didn't bother for this quick test
(02:54:30 PM) sgallagh: jwb: Ok
(02:55:37 PM) wwoods: sgallagh: very likely you don't even need a plugin, just need to tweak the provides/requires/etc. such that fedora-release-standard is preferred over its siblings
(02:56:06 PM) sgallagh: wwoods: I already went down this path originally and was told by the RPM/yum/dnf folks not to rely on that
(02:56:18 PM) sgallagh: Because DNF doesn't use the exact same resolution steps.
(02:56:43 PM) wwoods: this is the same problem we have with, say, sendmail/exim/esmtp
(02:59:01 PM) wwoods: err, exim/sendmail/postfix, I guess
(03:00:11 PM) wwoods: so how does DNF compare providers?
(03:00:45 PM) sgallagh: "differently"
(03:00:58 PM) sgallagh: It uses libsolv, IIRC
(03:01:16 PM) sgallagh: I haven't seen a nice breakdown of the comparison logic like the yum one
(03:05:39 PM) wwoods: anyway, my point is: yeah, of course it's *possible* for fedup (or yum, or dnf, or whatever) to circumvent the normal comparison rules
(03:06:26 PM) sgallagh: I think I have a workable idea on how to accomplish this, actually.
(03:06:42 PM) sgallagh: With some hackish tricks with versioned virtual Provides
(03:06:53 PM) wwoods: but I really don't want to add special code for that to fedup, because then we need to add it everywhere, or maintain it forever in fedup, or whatever
(03:08:18 PM) wwoods: sgallagh: yeah, every time this has come up, someone has figured out how to use the existing rules to make it do what they want
(03:08:58 PM) wwoods: I'm happy to help fix the comparison junk if it turns out that something is a) necessary and b) just totally not possible to do with the existing rules
(03:10:45 PM) sgallagh: wwoods: Mind if I run my hack past you so you can poke holes in it?
(03:11:23 PM) wwoods: sgallagh: feel free! although I can't guarantee to have any good answers
(03:11:34 PM) wwoods: I'm just a simple unfrozen caveman software developer, after all.
(03:12:52 PM) sgallagh: OK, so let's start by talking about the F21 packages.
(03:14:04 PM) sgallagh: on fedora-server-standard, we add 'Provides: fedora-server-product = %{version}-%{release}.2'
(03:14:04 PM) sgallagh: on each fedora-server-$PRODUCT, we add 'Provides: fedora-server-product = %{version}-%{release}.1'
(03:14:19 PM) sgallagh: errr s/fedora-server/fedora-release/
(03:14:34 PM) sgallagh: (I spend too much time thinking about Fedora Server...)
(03:15:03 PM) fenrus02: why the trailing .1 ?
(03:15:11 PM) sgallagh: The fedora-release package gets 'Requires: fedora-release-product >= %{version}-%{release}
(03:15:40 PM) sgallagh: fenrus02: So that, all other things being equal, fedora-release-standard will be picked, unless one of the others is already there.
(03:15:48 PM) sgallagh: I *think*
(03:15:52 PM) wwoods: sgallagh: I think that could get weird - it might end up considering f-r-standard an upgrade for f-r-cloud etc.
(03:16:12 PM) sgallagh: That's what I was afraid of
(03:17:33 PM) wwoods: best to talk to Packaging Experts about this, it's a not-uncommon problem
(03:18:00 PM) wwoods: I'm pretty certain there are Ways to deal with it but I personally don't know what they are
(03:19:09 PM) ***sgallagh nods
(03:19:20 PM) sgallagh: OK, I'll take it up with akuzompl or panu tomorrow
(03:19:40 PM) sgallagh: At this point, my brain is just about full for the day
(03:20:06 PM) wwoods: OTOH this might just be an unsolved problem, given how it keeps coming back - see sendmail/postfix/exim, rsyslog/syslog-ng/systemd, etc.
(03:20:51 PM) wwoods: on the OTHER other hand, didn't we just get Suggests/Recommends in RPM 4.12?
(03:22:39 PM) wwoods: so fedora-release could Require: fedora-release-product and Recommend: fedora-release-standard, or something
(03:22:54 PM) _tstclair is now known as tstclair
(03:24:26 PM) wwoods: (or I guess "Suggests:" is the weaker version)
(03:26:46 PM) wwoods: I'd hope that the depsolving code would take that as a hint to prefer the named package if there are multiple providers

-------------- 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/20141003/7e56e18f/attachment.sig>