Just a note that python26 is in main epel updates now and we can build python26 versions of needed packages against it.
There are some pending review currently, you can see them at:
https://bugzilla.redhat.com/buglist.cgi?short_desc=python26&short_desc_t...
There are a few that have already passed review, so you can take a look at those to get an idea of how things should be setup.
Reviewers and submitters of new packages welcome. :)
Help build our python26 ecosystem. ;)
kevin
Hello Kevin,
Reviewers and submitters of new packages welcome. :)
I had to rebuild the following two packages so that they are python26 modules:
python26-mod_wsgi http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-mod_wsg...
python26-virtualenv http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-virtual...
I basically took the related EPEL python-* SRPMs and changed the spec file to point to python26.
Please note that both are incompatible with the related python-* versions in EPEL. (this could probably be fixed for virtualenv by renaming the /usr/bin/virtualenv in /usr/bin/virtualen26, but I found not easy way to do so)
No need to say that we would be more than happy to have them maintained in EPEL, since they are nothing but a rebuild of the existing EPEL packages.
Would you be interested?
Cheers,
Mathieu
On Mon, Oct 04, 2010 at 08:35:00PM +0200, Mathieu Baudier wrote:
Hello Kevin,
Reviewers and submitters of new packages welcome. :)
I had to rebuild the following two packages so that they are python26 modules:
python26-mod_wsgi http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-mod_wsg...
mod_wsgi will need some work above and beyond simply rebuilding so that we can get the python-library-it's-built-against right. When we add mod_wsgi we'd have:
mod_python mod_wsgi python26-mod_wsgi
I believe that a later version of mod_wsgi can also be built against python-3.x so then we'd also have python3-mod_wsgi
In Fedora we'd probably handle this with the apache config files that check whether incompatible modules are loaded and if not, then load the module.
In EPEL, maybe you want to allow explicit Conflicts tags to take care of this case? (It would be a difference between Fedora and EPEL packaging guidelines but it may make sense.)
python26-virtualenv http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-virtual...
Could you tell me why you need to have a python-2.6 version of virtualenv? My use of virtualenv has been as a program rather than as a library. As a program, the python-virtualenv package should be able to create a python26 virtualenv just as easily as it can create a python24 virtualenv.
-Toshio
On Oct 4, 2010, at 3:49 PM, Toshio Kuratomi wrote:
On Mon, Oct 04, 2010 at 08:35:00PM +0200, Mathieu Baudier wrote:
Hello Kevin,
Reviewers and submitters of new packages welcome. :)
I had to rebuild the following two packages so that they are python26 modules:
python26-mod_wsgi http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-mod_wsg...
mod_wsgi will need some work above and beyond simply rebuilding so that we can get the python-library-it's-built-against right. When we add mod_wsgi we'd have:
mod_python mod_wsgi python26-mod_wsgi
I believe that a later version of mod_wsgi can also be built against python-3.x so then we'd also have python3-mod_wsgi
In Fedora we'd probably handle this with the apache config files that check whether incompatible modules are loaded and if not, then load the module.
In EPEL, maybe you want to allow explicit Conflicts tags to take care of this case? (It would be a difference between Fedora and EPEL packaging guidelines but it may make sense.)
This same issue/question came up in my review for mod_python26:
https://bugzilla.redhat.com/show_bug.cgi?id=638362
Originally I had an explicit 'Conflicts: mod_python' which was inherited from the package in IUS (based on IUS policy). The packages conflict because they both provide python_module. As noted in the ticket... even if mod_python26 was patched to work side-by-side with mod_python... all of the Apache directives provided by python_module and/or python26_module would still conflict.... meaning they can't be installed and run simultaneously. The options seem to be:
* Make the package explicitly conflict * Add an IfModule check for python_module, and if it isn't already loaded then load from mod_python26
To me, the first option is very clear and makes sense. From a users perspective... if they install mod_python26 while mod_python is installed... they may be a bit confused as to why mod_python26 just "doesn't work".
Would be helpful to get some more feedback from the list on which approach to take. The IfModule approach is fine as long as /etc/httpd/conf.d/python26.conf is commented clearly.. and assuming the end users reads the comments in the file.
--- derks
On Mon, Oct 04, 2010 at 07:46:22PM -0500, BJ Dierkes wrote:
On Oct 4, 2010, at 3:49 PM, Toshio Kuratomi wrote:
On Mon, Oct 04, 2010 at 08:35:00PM +0200, Mathieu Baudier wrote:
Hello Kevin,
Reviewers and submitters of new packages welcome. :)
I had to rebuild the following two packages so that they are python26 modules:
python26-mod_wsgi http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-mod_wsg...
mod_wsgi will need some work above and beyond simply rebuilding so that we can get the python-library-it's-built-against right. When we add mod_wsgi we'd have:
mod_python mod_wsgi python26-mod_wsgi
I believe that a later version of mod_wsgi can also be built against python-3.x so then we'd also have python3-mod_wsgi
In Fedora we'd probably handle this with the apache config files that check whether incompatible modules are loaded and if not, then load the module.
In EPEL, maybe you want to allow explicit Conflicts tags to take care of this case? (It would be a difference between Fedora and EPEL packaging guidelines but it may make sense.)
This same issue/question came up in my review for mod_python26:
https://bugzilla.redhat.com/show_bug.cgi?id=638362
Originally I had an explicit 'Conflicts: mod_python' which was inherited from the package in IUS (based on IUS policy). The packages conflict because they both provide python_module. As noted in the ticket... even if mod_python26 was patched to work side-by-side with mod_python... all of the Apache directives provided by python_module and/or python26_module would still conflict.... meaning they can't be installed and run simultaneously. The options seem to be:
- Make the package explicitly conflict
- Add an IfModule check for python_module, and if it isn't already loaded then load from mod_python26
To me, the first option is very clear and makes sense. From a users perspective... if they install mod_python26 while mod_python is installed... they may be a bit confused as to why mod_python26 just "doesn't work".
<nod> -- In Fedora we want to steer clear of Conflicts so we want to go with the second option but: 1) There's less versions of python there (only a single python2 and a single python3) and 2) EPEL has a different audience than Fedora with different needs. I think this is definitely something that EPEL could ponder upon and write into the EPEL-specific Guidelines as a difference.
-Toshio
Could you tell me why you need to have a python-2.6 version of virtualenv? My use of virtualenv has been as a program rather than as a library. As a program, the python-virtualenv package should be able to create a python26 virtualenv just as easily as it can create a python24 virtualenv.
Actually I had tried this but it had failed somehow (we were in the middle of debugging the deployment of a pretty complex app integrating Django with Tomcat etc.) Then I had deployed virtualenv manually, and then thought I should build a python-* package.
I tried again on a clean settings and you're right, it works: sudo virtualenv -p /usr/bin/python26 /opt/geonode3
So, good news, we can forget about this one.
epel-devel@lists.fedoraproject.org