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. -- 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
