(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= 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