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

[Stephen Gallagher]

On Sat, 2014-11-22 at 11:43 -0800, Adam Williamson wrote:
> 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.
> 

That's actually incorrect. The way that --product flag in fedup works is
that it modifies the upgrade transaction to include the
@^server-product-environment env-group (which in turn explicitly
includes the fedora-release-server package).

The net result is that an upgrade with the --product=server flag should
get you the union of the packages currently on your system plus those in
the standard Server install.


> > 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's a little tricky to explain, but the tl;dr version is that we needed
to make sure that the correct firewalld-config-* package is pulled in if
you needed to install it on a system that didn't previously have
firewalld (such as doing a Fedora Cloud install and then "promoting" it
to Fedora Server, which is the single case of Product swapping we plan
to officially support). Just conflicting with firewalld-config-$OTHERS
wasn't sufficient, because yum and dnf don't continuously iterate
through. So we needed to be able to compare in a single pass all of the
firewalld-config-* packages against the packages already installed on
the system.

The actual details on this are esoteric and murky (and frankly I don't
remember all of them anymore after four months). Suffice to say, I spend
a lot of time with Toshio and the yum and DNF developers until we
finally found a <strikeout>hack</strikeout> solution that actually
worked.

As noted on the Packaging guidelines, this is a temporary measure: we
really want the upcoming advanced dependency work in DNF to solve this
in a smarter way (they're planning to introduce a dep-specification
language that should solve this better).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20141126/08bcff06/attachment.sig>