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

[poma]

On 22.11.2014 20:43, Adam Williamson wrote:
> On Sat, 2014-11-22 at 20:19 +0100, Michael Schwendt wrote:
>> 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).
> 
> If we wanted to do that we could have done it with the current design -
> have fedora-release-nonproduct be the only package that obsoletes the
> older fedora-release. Presumably it wasn't desired.
> 
> The definition of a Product is not, at present, 'has these and only
> exactly these packages installed', it's more 'has at least these
> packages installed'. It's all still being figured out, but it was
> considered reasonable to let people mark upgrading systems as a given
> product. Though yes, there are obviously problems here, like if you
> upgrade a system and mark it as 'Server' it won't necessarily get
> rolekit as that's in the comps group not a dependency of the -release
> package.
> 
>>>>  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. ;)
> 
> What would have been the advantage? fedora-release doesn't conflict with
> any of the product packages. The product packages conflict with each
> other. I still don't see anywhere this design clearly improves on the
> current one, they seem to be to be effectively identical.
> 
>>>> 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?
> 
> It was in one of the devel@ threads, I believe. They're long threads.
> 
>>>>  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?
> 
> I'm not sure why it does that either. I'd think the conflict with
> firewalld-config-workstation and firewalld-config-server would be
> sufficient.
> 

It seems to me that you are the only one who understands what is written here. :)