Created attachment 1018020 [details] Backported patch from Rawhide Description of problem: When we created the os-release patches for Fedora 22, we missed backporting one change from Rawhide (aec40b478cd0486ec1312551961d1af3606a6685). Because of this, packages upgraded from F21 are not getting the VARIANT assigned in /etc/os-release. Version-Release number of selected component (if applicable): fedora-release-22-0.15.noarch fedora-release-cloud-22-0.15.noarch fedora-release-server-22-0.15.noarch fedora-release-workstation-22-0.15.noarch How reproducible: Every time Steps to Reproduce: 1. Install a Fedora 21 Server or Workstation system. 2. Update it to the latest packages and then run 'fedup --network 22' Actual results: /etc/os-release is missing VARIANT Expected results: /etc/os-release should have VARIANT=Server or VARIANT=Workstation (as appropriate) Additional info: Clean installations of Fedora 22 behave correctly. Updates to Rawhide are also handled properly; this is only an issue of Fedora 22.
What git repository holds the commit aec40b478cd0486ec1312551961d1af3606a6685 ? I don't see it. Personally I find this hard to review as there's quite a lot of interactions; how things worked in F21 vs F22, the initial install vs upgrade semantics of yum/fedup, etc. But the code that's now run every time looks safe to me. I did verify that we still have the `systemctl preset` protected by initial install guards.
fedora-release-22-0.15 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/fedora-release-22-0.15
(In reply to Colin Walters from comment #1) > What git repository holds the commit > aec40b478cd0486ec1312551961d1af3606a6685 ? I don't see it. > https://git.fedorahosted.org/cgit/fedora-release.git/commit/?id=aec40b478cd0486ec1312551961d1af3606a6685 > Personally I find this hard to review as there's quite a lot of > interactions; how things worked in F21 vs F22, the initial install vs > upgrade semantics of yum/fedup, etc. > Yeah, that's an unfortunate side-effect due to the extremely complicated approach I took in F21. Fortunately going forward, basing the decisions off the VARIANT in /etc/os-release should be significantly simpler. There's one minor "gotcha" here. In F23 we're going to have to modify this *very* slightly again, because upstream systemd has decided that VARIANT needs to have both VARIANT (human-readable) and VARIANT_ID (machine-parseable) versions. Though I suppose since we're pre-release still, we could probably still do this in F22. Thoughts? > But the code that's now run every time looks safe to me. I did verify that > we still have the `systemctl preset` protected by initial install guards. Thanks for the review.
Package fedora-release-22-0.15: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedora-release-22-0.15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7298/fedora-release-22-0.15 then log in and leave karma (feedback).
fedora-release-22-0.15 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.