On Sat, 22 Nov 2014 11:43:52 -0800, Adam Williamson wrote: > > 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? A matter of design -- it would lead to a different result. The possibility to replace an unknown installation (-> "fedora-release" only) with -nonproduct and to get rid of the "fedora-release requires system-release-product" dependency, because there would be only a single system-release-product provider in the single installed fedora-release-product package. If one had agreed on avoiding conflicts (or reducing them to a minimum, such as the fedora-release-* packages), that would have resulted in different requirements for the implementation at the package level. For example, _no_ conflict between firewalld-config-* and fedora-release-* packages. Discontinueing/replacing a package also makes it necessary to revisit all dependencies on it and eliminate problematic (or wrong or unsafe or ambiguous or superfluous) explicit dependencies. If, however, one considers explicit Conflicts between packages the first or easiest "solution", or "a hack" that's "good enough", well, it's a different design IMO. In this case a solution has been searched for at the package level, which likely made it less easy to avoid conflicts. > 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. At the risk of repetition: An installation of Fedora 20 or older is not comparable to any of these new products, IMO. During upgrade, it cannot be identified by examining what packages are installed. It could be anything. With no conflicts related to the firewalld-config-* packages, turning an installation of Fedora 20 or older into a product (or non-product, whatever) does not bear any risk of running into a conflict during upgrade or later. Just like *any* package from Fedora Everything could be found installed already, so could be any firewalld-config package - and with the config to be enabled/disabled at run-time. I would have preferred avoidance of conflicts as a design goal. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
