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

[Michael Schwendt]

On Sat, 22 Nov 2014 08:45:51 -0800, Adam Williamson wrote:

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

No.

There would be only a single package that _replaces_ the fedora-release
package via Obsoletes. Under the assumption that the given installation
to be upgraded could be _anything_, sort of an unknown product or a
non-product.

You cannot upgrade that installation into a well-defined "product". You
would need to remove anything that's not part of the new product, and if
you don't do that, the upgrade bears the risk of running into conflicts
(prompting the user or letting the depsolver try to be clever and likely
need into fatal problems).

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

Yet one could have _discontinued_ the old fedora-release package and
moved its files into a _new_ and _non-conflicting_ *-common package. ;)

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

Do you (or anyone else) know of a prominent place/thread where this
design decision has been discussed?

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

Which sounds like the wrong tool has been chosen for the job, *if*
explicit (or even implicit) conflicts could not be avoided in the
dependencies as opposed to a very few specific -product packages only.

That is, fedora-release-product1 conflicting with fedora-release-product2,
okay, two packages of the same type or purpose, but
firewalld-config-standard conflicting with fedora-release-workstation?
Those are troublesome conflicts. It's an attempt at trying to control
what packages can be installed - something that isn't possible anyways
(unless one points the products at a set of product-specific repos).

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

Thanks for explaining that, Adam.