NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG Meeting (every Monday at 19:30 UTC). Hello all, I would like to start an official discussion regarding the current policy on conflicting packages. Currently, the EPEL documentation [1] is a bit sparse and does not reflect certain situations (such as the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora packagers should avoid an explicit 'Conflicts: xxxxx' as much as possible. However, due to some new developments in EPEL 5 (namely python26), some situations may require explicitly conflicting packages. As an example, during my package review for mod_python26 [3] the subject was brought up due to my use of 'Conflicts: mod_python' in the spec for mod_python26. The packages conflict because mod_python and mod_python26 both provide the 'python_module', and the same Apache directives when enabled. Therefore, the two can not be loaded at the same time. The issue would be the same for mod_wsgi and mod_wsgi26 (built against/for python26). In this specific situation, the possible solutions to work around this are: * Change policy to account for situations like those related to python26 and allow explicit 'Conflicts: xxxxx' * Silently disable mod_python26 if python_module is already loaded via IfModule [4] Though the second option (IfModule) is a cleaner approach, it hides the fact that mod_python26 just won't load if mod_python is installed/enabled and assumes the user will know to look at /etc/httpd/conf.d/mod_python26.conf for comments on why that might be. On the other hand, conflicting with mod_python doesn't inform the user why it conflicts... it just conflicts. In my opinion it would be slightly more obvious why mod_python26 would Conflict: mod_python, but I don't know what is collectively in the best interest of EPEL maintainers. In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and would be troubling/confusing for a lot of users. However, being that EPEL is a different audience and different use case... I would like to open discussion regarding current policy and determine, officially, how these situations should be handled. References: [1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Confl... [2] http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts [3] https://bugzilla.redhat.com/show_bug.cgi?id=638362 [4] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkysWyYACgkQeiVVYja6o6Oy1gCggE4c3nDPDlQykgEy6WaKLIZ0 JQUAn10CqNjh7MucoTao+Nn034vYqDis =1w/0 -----END PGP SIGNATURE-----

NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG Meeting (every Monday at 19:30 UTC). Hello all, I would like to start an official discussion regarding the current policy on conflicting packages. Currently, the EPEL documentation [1] is a bit sparse and does not reflect certain situations (such as the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora packagers should avoid an explicit 'Conflicts: xxxxx' as much as possible. However, due to some new developments in EPEL 5 (namely python26), some situations may require explicitly conflicting packages. As an example, during my package review for mod_python26 [3] the subject was brought up due to my use of 'Conflicts: mod_python' in the spec for mod_python26. The packages conflict because mod_python and mod_python26 both provide the 'python_module', and the same Apache directives when enabled. Therefore, the two can not be loaded at the same time. The issue would be the same for mod_wsgi and mod_wsgi26 (built against/for python26). In this specific situation, the possible solutions to work around this are: * Change policy to account for situations like those related to python26 and allow explicit 'Conflicts: xxxxx' * Silently disable mod_python26 if python_module is already loaded via IfModule [4] Though the second option (IfModule) is a cleaner approach, it hides the fact that mod_python26 just won't load if mod_python is installed/enabled and assumes the user will know to look at /etc/httpd/conf.d/mod_python26.conf for comments on why that might be. On the other hand, conflicting with mod_python doesn't inform the user why it conflicts... it just conflicts. In my opinion it would be slightly more obvious why mod_python26 would Conflict: mod_python, but I don't know what is collectively in the best interest of EPEL maintainers. In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and would be troubling/confusing for a lot of users. However, being that EPEL is a different audience and different use case... I would like to open discussion regarding current policy and determine, officially, how these situations should be handled. References: [1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Confl... [2] http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts [3] https://bugzilla.redhat.com/show_bug.cgi?id=638362 [4] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule --- derks _______________________________________________ epel-devel-list mailing list epel-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list

So, some more questions I have: * Would this conflicts case be restricted to just these python26-mod* packages? Or is this more general? I can see the case for packages that use a parallel installable stack and can't load at the same time, but I worry that we should make sure this isn't used more broadly.