Some/all of the Fedora 21 Beta TC4 non-Product images, including the release-blocking KDE image, have generic-release and generic-release-rawhide instead of fedora-release, fedora-repos and fedora-release-nonproduct . My working theory at present is that this is because we forgot fedora-release and generic-release are really in a race to provide system-release (which the 'setup' package depends on). By adding an extra dependency to fedora-release (for 'system-release-product') we made yum prefer generic-release, because it can satisfy the dependency with a smaller dep chain. I think the appropriate way to fix this is to make generic-release mirror fedora-release, because we *do* want it to be possible to pick either, but for fedora-release to win out when neither is explicitly specified. At least, I think that's what we want.
Proposing as a Beta blocker, Alpha criterion: "The installed system must be able to download and install updates with the default console package manager." - https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Updates it can't do that properly because it has generic-release-rawhide, i.e. it has Rawhide repositories. It gets F22 updates, not F21. It's arguably also a violation of "Any component which prominently identifies a Fedora release version number, code name or milestone (Alpha, Beta, Final) must do so correctly." because it identifies as Generic, not Fedora.
hm, doesn't affect a minimal netinst from the server netinst ISO, not sure why. that gets fedora-release-nonproduct.
oh, because the 'minimal' install in the GUI is actually an environment group and explicitly lists fedora-release-nonproduct. Probably would still affect someone using a kickstart with just @core.
I pushed https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=bfa7d4e4f614a289ee04936371202cb66f11303d which should fix up the immediate problem of KDE spin being broken. It won't fix the issue with custom kickstarts that only list @core though; this needs more thought.
you don't want to add -nonproduct to the workstation package set, that's wrong. It gets fedora-release-workstation via the workstation-product comps group, which is what it should have.
I misread Kalev's change in c#5, it's internally consistent. It's arguable whether it's best to add -nonproduct to the base kickstart then have Product kickstarts override it, or add -nonproduct to all the non-Product kickstarts separately...but meh, just bikeshed painting really.
Note that I have a bug against generic-release asking for support for a generic version of workstation. While I wasn't planning on making a change before beta because of the risk of breaking things, you might want to keep bug 1154154 in mind when designing fixes.
The way things are supposed to work, if you remove a package in a kickstart that the package can't get pulled back in later. So doing -generic-* in a kickstart file should keep any generic packages from being used. However this is a relatively new feature and maybe something changed it back to the way it used to work. In the past you need to do excludes in the repo command in order to keep packages from getting pulled in by dependencies.
Discussed in 2014-10-20 Blocker Review meeting [1]. Accepted as a blocker. This bug is a clear violation of the Alpha Updates criteria: "The installed system must be able to download and install updates with the default console package manager." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-20/
I just noticed that with my custom kickstart install I ended up with generic-release and generic-release-rawhide. To install fedora-release-workstation I also need to specify firewalld-config-workstation to avoid a conflict with firewalld-config-standard. I imagine more such conflicts may occur in the future. It would be nice to have a solution that didn't put too much onus on the kickstart writer to get the right package set.
So pbrobinson added something to fedora-arm-minimal.ks for this, different from what Kalev did for lives: [adamw@adam spin-kickstarts (master %)]$ git diff 8c34b5ffa988f7e772de39d9d27436c435590109 fedora-arm-minimal.ks diff --git a/fedora-arm-minimal.ks b/fedora-arm-minimal.ks index fd88555..3b6a480 100644 --- a/fedora-arm-minimal.ks +++ b/fedora-arm-minimal.ks @@ -7,6 +7,7 @@ part / --size=1400 --fstype ext4 -@standard -@dial-up -initial-setup-gui +-generic-release* %end %post but he didn't do anything for fedora-arm-lxde.ks, or fedora-arm-xfce.ks , or any of the others. Basically we've got kind of a mess here, no-one's taking an overview of the right way to fix it. I'm not sure anyone's thinking about preserving the *intended* use of the generic packages, either - has anyone actually considered how you'd do a de-branded version of Fedora now? It was already a bit of a pain with me for Fedlet last month, it's probably worse now; I'll find out next time I need to do a build, I guess.
FWIW I would propose we have generic-release mirror fedora-release precisely, *including* that it should produce generic-release-workstation , generic-release-server , generic-release-cloud , generic-release-nonproduct subpackages. We should continue the system of having 'system-' virtual provides for both fedora-foo and generic-foo: fedora-release-server and generic-release-server both Provides: system-release-server fedora-release-workstation and generic-release-workstation both Provides: system-release-workstation etc. In comps, the Product / product environment groups would list system-release-foo, not fedora-release-foo. We'd have fedora-XXX-packages.ks files for *every* Product / product in spin-kickstarts, and both the ARM and live kickstarts would include the fedora-XXX-packages.ks files. That I think should make things rather more consistent?
(In reply to Adam Williamson (Red Hat) from comment #11) > So pbrobinson added something to fedora-arm-minimal.ks for this, different > from what Kalev did for lives: At the time I pushed the "fix" I wasn't aware it was a wider problem, I thought it was just the minimal image (the TC wasn't completely finished composing) that had the issue and I did the fix based on what clous/server had done in the past: $ grep generic-release *ks fedora-arm-minimal.ks:-generic-release* fedora-install-cloud.ks:-generic-release* fedora-install-server.ks:-generic-release* $ But I agree, it's a horrible hack and the cross references between various packages and conflicts etc being added appears to be a bit of a hack.
Created attachment 948750 [details] generic-release.spec diff Here's a rough cut of the diff for generic-release.spec to bring it into line with fedora-release.spec. It would require the Server source files be pulled into the generic-release tarball. Bruno is in charge of generic-release for now, I believe.
I don't claim to be in charge. I tried to solve a problem where we needed to rebuild it to fix a problem triggered by a yum change and found there wasn't a source upstream for soem of the stuff in the package. Dennis didn't like the approach I took for the package, in part because he would like to see the same process used to update both fedora-release and generic-release. I am not tied to anything I did. I think it would be better if both came from the same upstream, but I didn't see any easy way to derive generic-release from fedora-release. There is a generic-release upstream on fedorahosted that I can give other people access to or we can just scrap it.
Let's say for blocker purposes this is modified, as we expect release blocking images for Beta should be OK for TC5/RC1.
(In reply to Adam Williamson (Red Hat) from comment #11) > So pbrobinson added something to fedora-arm-minimal.ks for this, different > from what Kalev did for lives: > > [adamw@adam spin-kickstarts (master %)]$ git diff > 8c34b5ffa988f7e772de39d9d27436c435590109 fedora-arm-minimal.ks > diff --git a/fedora-arm-minimal.ks b/fedora-arm-minimal.ks > index fd88555..3b6a480 100644 > --- a/fedora-arm-minimal.ks > +++ b/fedora-arm-minimal.ks > @@ -7,6 +7,7 @@ part / --size=1400 --fstype ext4 > -@standard > -@dial-up > -initial-setup-gui > +-generic-release* > %end > > %post > > but he didn't do anything for fedora-arm-lxde.ks, or fedora-arm-xfce.ks , or > any of the others. > > Basically we've got kind of a mess here, no-one's taking an overview of the > right way to fix it. I'm not sure anyone's thinking about preserving the > *intended* use of the generic packages, either - has anyone actually > considered how you'd do a de-branded version of Fedora now? It was already a > bit of a pain with me for Fedlet last month, it's probably worse now; I'll > find out next time I need to do a build, I guess. I don't know of any projects using the de-branded / remix tools besides mine (http://znmeb.github.io/CompJournoStick/). I hit one bug in the Fedora 20 cycle (https://bugzilla.redhat.com/show_bug.cgi?id=1031288) and one just recently in Fedora 21 (https://bugzilla.redhat.com/show_bug.cgi?id=1154154). Going forward after Fedora 21 *release*, I'm hoping to refactor CompJournoStick into Workstation, Server and Cloud components to match Fedora's. I certainly won't be doing that before the release.
(In reply to Bruno Wolff III from comment #7) > Note that I have a bug against generic-release asking for support for a > generic version of workstation. While I wasn't planning on making a change > before beta because of the risk of breaking things, you might want to keep > bug 1154154 in mind when designing fixes. I'm testing generic-release-21-7 now and it appears to have fixed bug 1154154. It also fixes bug 1154812 but I don't have a test case for that one.
(In reply to Adam Williamson (Red Hat) from comment #1) > Proposing as a Beta blocker, Alpha criterion: > > "The installed system must be able to download and install updates with the > default console package manager." - > https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Updates > > it can't do that properly because it has generic-release-rawhide, i.e. it > has Rawhide repositories. It gets F22 updates, not F21. It's arguably also a > violation of "Any component which prominently identifies a Fedora release > version number, code name or milestone (Alpha, Beta, Final) must do so > correctly." because it identifies as Generic, not Fedora. For what it's worth, generic-release-21-7 does not provide generic-release-rawhide.
I've added the 'explicitly list @fedora-release-nonproduct' hack to fedora-arm-base.ks just now to match fedora-live-base.ks and hopefully avoid this problem in at least the release-blocking images for Beta. Post-Beta we should drop the hacks, push generic-release-21.7 stable, and revise the kickstarts to use the environment groups, I'd suggest.
(In reply to Adam Williamson (Red Hat) from comment #20) > I've added the 'explicitly list @fedora-release-nonproduct' hack to > fedora-arm-base.ks just now to match fedora-live-base.ks and hopefully avoid > this problem in at least the release-blocking images for Beta. > > Post-Beta we should drop the hacks, push generic-release-21.7 stable, and > revise the kickstarts to use the environment groups, I'd suggest. And add a bit more documentation on how this all works for people who are doing remixes. I figured out how to build a remix with a name other than "Generic" last night on my own. ;-)
ed: BTW, my own Fedlet - https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/ - uses the generic-release bits, as it's not allowed to be branded as Fedora. I'm guessing Korora might too.
Beta RC1 testing does not seem to have turned up any cases where this is still causing a problem after the spin-kickstarts changes, so let's called it fixed (there are no packages that need to go stable as all the adjustments were in spin-kickstarts).