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

[Adam Williamson]

On Sat, 2014-11-22 at 13:01 +0100, Michael Schwendt wrote:
> On Fri, 21 Nov 2014 10:07:32 -0800, Adam Williamson wrote:
> 
> > 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'.
> 
> Yum is known for pulling in "odd packages" for the case of a dependency
> where "any provider suffices". Originally, it had been "shorted %name
> wins", but even the developers on certain occasions told that it is not as
> simple as that. Dunno what it's like nowadays. It has lead to breakage
> several times, because behaviour changed, and users+packager could not
> rely on a "yum install ..." to pull in a predictable set of packages.
> 
> Anyway, one can read it is being worked on within DNF and/or RPM.

Yes, I know that. What I'm saying is that you should rarely be in the
case where yum is just trying to solve a requirement for
'system-release-product' without any other information. The intent is
that in all the commonly-encountered cases where the dependency is
encountered, the transaction will already include a specific product
package, as I explained in quite a bit of detail in the initial post.

> > 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.
> 
> This concept of "switching products" sounds strange with regard to
> Upgrades from Fedora 20 or older. Before, users could install anything
> (not "everything" because of too many conflicts :
>   http://smoogespace.blogspot.de/2011/05/doing-everything-install.html )
> which made the install result in something that does not closely resemble
> one of the new products.

If your install doesn't closely resemble any of the products, then it
seems obvious to choose 'nonproduct' as your 'product' package on
upgrade.

>  I wonder whether an upgrade path from Fedora 20
> could have been from fedora-release < 21 to a non-product release via a
> single well-defined Obsoletes instead of an arbitrary one? Why not discontinue
> the old fedora-release package in favour of introducing new $product
> specific release packages?

Well, then you'd just have to duplicate a bunch of stuff between all the
product-specific packages, and it still doesn't solve this problem,
because anything that previously depended on fedora-release would now
have to depend on a virtual provide provided by any of the
fedora-release-(product) packages, which is...exactly what you're
complaining about. No?

>  Yum as upgrade method may not be supported,
> but why do I get two fedora-release* packages for a fresh install of
> Fedora 21 Beta, too?

Just sensible package splitting. All the Products are still, to some
extent, Fedora, and share a bunch of common 'release'-y information,
which is contained in fedora-release. The bits of 'release'-y
information that are specific to each Product are in the product
subpackage.

> It also surprises me that the "solution" that has been presented to FPC
> does not try to solve the conflicts at run-time. Why do the packages need
> to conflict?

AIUI, this is because it was decided we don't want to try and
allow/support having 'multiple products installed'.

>  Why can't non-conflicting configuration files be installed
> into a foo.d directory with a switch to be toggled in a config file?

The release stuff isn't just about configuration files, for a start -
some products at least started implementing package dependencies in
their -product subpackage, for instance, though that caused another
problem which I had some fun debugging.

> True. I haven't found an explanation why the physical packages must
> conflict? And as above, why stuff like firewall configuration cannot be
> handled at the configuration level? Has this even be considered?

I don't honestly recall the details of what was considered and what
wasn't, but I'll say this - most of the problems showed up as we went
along, this is one of those cases where it's really hard to think
through all the possible consequences in advance. I'd have been happier
if all this stuff had been in place by Alpha or earlier, and then we
would have more of a chance to revise/improve/fix it. Right now we're
pretty much stuck with seat-of-the-pants minimal fixes to the crap
that's in place. I'm not entirely happy with how the Product stuff was
handled either, but I don't want to crap on the people who tried their
best; I just wish it'd all been done earlier and with a more forgiving
schedule, so we had time to fix the inevitable problems as they
appeared, or change course on the design if it seemed like we were onto
a bad one.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net