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? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
