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).
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
