On Sat, 2014-11-22 at 13:01 +0100, Michael Schwendt wrote: > 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. Yes, I know that. What I'm saying is that you should rarely be in the case where yum is just trying to solve a requirement for 'system-release-product' without any other information. The intent is that in all the commonly-encountered cases where the dependency is encountered, the transaction will already include a specific product package, as I explained in quite a bit of detail in the initial post. > > 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. If your install doesn't closely resemble any of the products, then it seems obvious to choose 'nonproduct' as your 'product' package on upgrade. > 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? > 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. > 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'. > 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. > 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
