Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch

[Adam Williamson]

On Fri, 2014-11-21 at 11:29 +0100, Michael Schwendt wrote:
> On Thu, 20 Nov 2014 14:01:07 -0800, Adam Williamson wrote:
> 
> > > 	system-release-product is needed by (installed) fedora-release-21-0.16.noarch
> > > 
> > > As one can see, it's some virtual package or "capability", but not a direct
> > > or strict dependency on "fedora-release-cloud".
> > 
> > Yes. That's not "a random generic dependency".
> > 
> > > Even the "fedora-release-nonproduct" package provides "system-release-product".
> 
> > [...]
> >
> > The cloud package really doesn't
> > involve itself in that issue; cloud tends to crop up when you're
> > struggling with this simply because it tends to be the winner when yum
> > tries to solve the system-release-product requirement without any hints
> > (I think because it has the equal-shortest dep chain of any of the
> > packages that provide system-release-product , and comes first
> > alphabetically among all those with the shortest dep chain).
> 
> So many words for what I call "a random generic dependency" => any provider
> of that "thing" can win the depsolving => boom! Or "doom" for the case of
> an explicit (or even implicit) conflict.
>
> Case closed for me. I think this is broken severely and ought to have
> been avoided.

Well, you're never supposed to be in a case where you're relying on yum
to solve it without any hints, it's not really 'random'. On new installs
you have to pick an environment group, and every environment group
requires a specific product package (custom kickstarts that don't use
one of the environment groups or explicitly specify a product package
will wind up with the 'default' resolution, but that's a bit of a corner
case). For upgrades, fedup requires you to pick one.

It's all very well to point at the problems and say it's bad, but no-one
came up with anything *better*. All the work on this Product stuff was
done in public, on devel@ and in bug reports and FESCo tickets and so
on. The people who did the work did the best they could; there are
various places where the result has issues, but it's a hard thing to do.

It's easy to just say it "should have been avoided", but it doesn't
really help anyone. If you have a concrete suggestion as to how to
implement the Product design without this problem, *that* would help (of
course, it would've helped more six months ago, when all this stuff
should really have been worked out).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net