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

[Michael Schwendt]

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.

> 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. 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? 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?

Sure, it's too late now. It just surprises me what has been come up with:
https://fedorahosted.org/fpc/ticket/446

   | Both yum and DNF have issues with handling Conflicts: at the 
   | appropriate phase of dependency-checking. As a result, we need [...]

which adds lots of explicit Conflicts, which are hard to handle.
Adding more Conflicts is like "admitting defeat".

https://fedorahosted.org/fpc/ticket/92

   | Error: generic-release conflicts with fedora-release-14-1.noarch
   |
   | Proposal to relax Conflicts is rejected. 

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

> 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.

Hard to comment on. I may have noticed threads such as
https://lists.fedoraproject.org/pipermail/devel/2014-July/200972.html
but missed the step where/when something was considered the way to go.

> 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).

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?