On Fri, 2014-10-17 at 17:56 -0700, Adam Williamson wrote: > On Fri, 2014-10-17 at 16:52 -0700, Adam Williamson wrote: > > On Sat, 2014-10-18 at 07:48 +0800, Ed Greshko wrote: > > > On 10/18/14 05:46, Andre Robatino wrote: > > > > As per the Fedora 21 schedule [1], Fedora 21 Beta Test Compose 4 (TC4) > > > > is now available for testing. > > > > > > Just installed the KDE Live "spin" to disk and upon bootup found that > > > the rawhide repo enabled while the rest of the repos were disabled. > > > > > > Intentional? > > > > No. I'm guessing it's a problem with the change of name in > > fedora-release - fedora-release-standard was changed to > > fedora-release-nonproduct. Either there's a problem in comps / > > spin-kickstarts, or we didn't wait long enough to do the compose, or > > something. I'll take a look, thanks for the note. > > Problem is in the fedora-release shenanigans that went into TC4 - > https://admin.fedoraproject.org/updates/FEDORA-2014-13090/fedora-release-21-0.16 - but I still need to plumb out exactly how. I think the fact that fedora-release now requires 'system-release-product' is contributing. > > If you look on the KDE live for TC4 it's actually got completely the > wrong release packages. It has the generic ones: > > [liveuser@localhost ~]$ rpm -qa | grep release > generic-release-rawhide-21-5.noarch > generic-release-21-5.noarch > fedora-release-notes-21.06-1.fc21.noarch > > so far what I figure is this. There isn't actually a lot in Fedora which > directly requires a *release package of some sort. I believe it's just > the package `setup`, which requires "system-release". Both > fedora-release and generic-release provide "system-release". > > If you use any kickstart to deploy Fedora which doesn't explicitly > specify one or other provider, you're ultimately going to get whatever > the depsolver gives you. > > The 'environment groups' in comps explicitly require a fedora-release > package (fedora-release-(product) in the case of Server, Workstation > etc; fedora-release-nonproduct in the case of KDE etc) so they're OK. > But the KDE live image doesn't actually use the > 'kde-desktop-environment' comps group, it just directly lists various of > the KDE package groups: > > %packages > @kde-apps > @kde-desktop > @kde-media > @kde-telepathy > @networkmanager-submodules > > (in fedora-kde-packages.ks). None of the other live images actually use > the environment groups either, they do something similar. Workstation is > OK in TC4 because the Workstation kickstart lists the > "workstation-product" comps group, and that lists the > 'fedora-release-workstation' package directly. > > You could say we should just go around sticking > fedora-release-nonproduct in a bunch of comps groups, but I'm not sure > that's quite the right answer - the whole point of having > generic-release in the first place is so people can do unbranded > Fedoras, and that would prevent people doing that. > > So, why does the depsolver suddenly start giving us generic-release > instead of fedora-release? I'm not sure yet, but I have a theory - I > believe fedora-release's dependency chain got longer, and that affects > the depsolver's choice. In fedora-release-21-0.16, a requirement was > added to fedora-release for 'system-release-product', which is provided > by fedora-release-server, fedora-release-nonproduct etc. But > 'generic-release' has no such matching requirement (nor do we in fact > have a generic-release-server, generic-release-workstation, > generic-release-nonproduct etc). > > So basically you get generic-release because it can satisfy the > 'system-release' requirement with a shorter dep chain, because it > doesn't also have to pull in a 'product' package to satisfy the > 'system-release-product' dep. > > I guess the straightforward way to fix this is just to bring > generic-release in line with fedora-release - if their depchains are > similar fedora-release wins out I believe alphabetically (man, this > stuff is hairy sometimes). > > It'd help if we had anyone around who remembers how the generic-* stuff > was originally architected to work, and what the expectations were > around how people should use it, I guess. > > I'll file a bug for this. What's the BZ number there? And I think your analysis is spot-on. We haven't been keeping the generic-release-* stuff up to date (I think because it's maintained separately from the fedora-release-* stuff). Dennis, do you have any insight here? I know when we talked a few months ago, you were planning to try to bring these two upstreams together so we could avoid this sort of thing. Any word on that?
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
