-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/11/2014 09:03 AM, Vít Ondruch wrote: > Dne 11.3.2014 13:25, Stephen Gallagher napsal(a): >> On 03/11/2014 02:46 AM, Vít Ondruch wrote: >>> Dne 10.3.2014 17:10, Toshio Kuratomi napsal(a): >>>> At last week's FESCo meeting, the fact that Products desired >>>> to have divergent configuration was briefly touched on. On >>>> Thursday, a few FPC members had a brainstorming session about >>>> it and on Friday, sgallagh and that brainstorming continued >>>> with sgallagh, adamw, tflink, notting, and myself. We came >>>> up with a tentative idea here: >>>> >>>> https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) >> >>>> >> >>>> >>>> >> The idea is to allow config file divergence via the alternatives >> system as >>>> that already provides us with a commandline tool and some >>>> structure to >>> build >>>> on. We'd still have to write a few pieces to complete the >>>> picture but it seemed to be a better starting point than >>>> using rpm Conflicts between config-packages. >>>> >>>> Anyone have thoughts on this potential path? >>>> >>>> -Toshio >>>> >>>> >> >> >>> With rich dependencies coming to Fedora, wouldn't be better to >>> wait for a bit and benefit from them? We would have product >>> specific configuration in subpackages and installed it such as >>> "Requires: fedora-product-cloud & foo-config-cloud; Requires: >>> fedora-product-server & foo-config-server". >> >> >> >> That unfortunately doesn't address the issue in a realistic way. >> I don't think there's a way that dependency resolution can >> resolve that in a positive way. The closest I can see coming up >> with would be: >> >> == foo == Requires: foo-config >> >> == foo-config-server == Provides: foo-config = 1.0 Conflicts: >> fedora-release-workstation Conflicts: fedora-release-cloud >> >> == foo-config-workstation == Provides: foo-config = 1.0 >> Conflicts: fedora-release-server Conflicts: fedora-release-cloud >> >> == foo-config-cloud == Provides: foo-config = 1.0 Conflicts: >> fedora-release-workstation Conflicts: fedora-release-server >> >> == foo-config-default == Provides: foo-config = 2.0 Conflicts: >> fedora-release-workstation Conflicts: fedora-release-server >> Conflicts: fedora-release-cloud >> >> So, if installed on a Product, yum would resolve whichever >> config subpackage doesn't hit any conflicts (which would be the >> matching version or the default, if not on a product). >> >> >> There are a couple down-sides to this approach: 1) It eliminates >> the possibility of having multiple Products installed on the same >> system. Whether we care about this is being debated elsewhere, >> but this approach would make it impossible. 2) It might make life >> a real pain in the neck to deal with adding new Products to >> Fedora, since any package providing custom authentication will >> have to tweak Provides: and Conflicts: to ensure that the new >> Product gets reasonable defaults. > > You are speaking about how to achieve that in current Fedora, if I > understand that correctly. I am speaking about F22, where RPM/DNF > should hopefully support rich dependencies. > - From what I've seen of the planned "rich" dependencies, I don't think they would provide any mechanism better than this one anyway. Can you explain how you would see this working, with a specific example? > BTW if each package contains the same file, lets say /etc/foo.cfg, > but the content of this file is different between the packages, > they conflicts without explicit conflict, if I am not mistaken. > File-level conflicts are expressly forbidden in Fedora, because they cannot be detected from the package metadata. You have to have the whole package downloaded to catch this. By that point, it's *really* difficult to restart the transaction and resolve the conflict. I think yum basically just fails at this point and expects you to re-run with a more detailed command-line. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMfDB0ACgkQeiVVYja6o6NqQACeNtF5zcvjdRvx9mrIW8NCfq99 2Z0AnRbz/nusUquwazY3Us0Tbv3dUlP8 =9yjM -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
