Bug 1154235 - fedora-release now loses to generic-release when racing to provide system-release: causes non-product F21 Beta TC4 images to be generic
Summary: fedora-release now loses to generic-release when racing to provide system-rel...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F21BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2014-10-18 01:07 UTC by Adam Williamson
Modified: 2014-10-27 18:21 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-27 18:21:16 UTC


Attachments (Terms of Use)
generic-release.spec diff (5.27 KB, text/plain)
2014-10-20 21:58 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2014-10-18 01:07:23 UTC
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.

Comment 1 Adam Williamson 2014-10-18 01:11:28 UTC
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.

Comment 2 Adam Williamson 2014-10-18 01:30:59 UTC
hm, doesn't affect a minimal netinst from the server netinst ISO, not sure why. that gets fedora-release-nonproduct.

Comment 3 Adam Williamson 2014-10-18 01:32:38 UTC
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.

Comment 4 Kalev Lember 2014-10-18 13:40:19 UTC
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.

Comment 5 Adam Williamson 2014-10-18 18:16:27 UTC
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.

Comment 6 Adam Williamson 2014-10-20 00:07:06 UTC
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.

Comment 7 Bruno Wolff III 2014-10-20 15:13:52 UTC
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.

Comment 8 Bruno Wolff III 2014-10-20 15:20:49 UTC
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.

Comment 9 Kamil Páral 2014-10-20 16:09:20 UTC
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/

Comment 10 Orion Poplawski 2014-10-20 21:05:41 UTC
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.

Comment 11 Adam Williamson 2014-10-20 21:37:51 UTC
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.

Comment 12 Adam Williamson 2014-10-20 21:42:10 UTC
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?

Comment 13 Peter Robinson 2014-10-20 21:46:13 UTC
(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.

Comment 14 Adam Williamson 2014-10-20 21:58:27 UTC
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.

Comment 15 Bruno Wolff III 2014-10-20 22:11:16 UTC
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.

Comment 16 Adam Williamson 2014-10-21 02:08:12 UTC
Let's say for blocker purposes this is modified, as we expect release blocking images for Beta should be OK for TC5/RC1.

Comment 17 M. Edward (Ed) Borasky 2014-10-22 19:01:58 UTC
(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.

Comment 18 M. Edward (Ed) Borasky 2014-10-22 23:25:52 UTC
(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.

Comment 19 M. Edward (Ed) Borasky 2014-10-23 09:28:24 UTC
(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.

Comment 20 Adam Williamson 2014-10-23 17:16:45 UTC
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.

Comment 21 M. Edward (Ed) Borasky 2014-10-23 20:10:58 UTC
(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. ;-)

Comment 22 Adam Williamson 2014-10-25 14:10:23 UTC
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.

Comment 23 Adam Williamson 2014-10-27 18:21:16 UTC
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).


Note You need to log in before you can comment on or make changes to this bug.