On 22.11.2014 20:43, Adam Williamson wrote: > 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. >
It seems to me that you are the only one who understands what is written here. :) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
