FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 09-27-2010, 08:23 PM
Kevin Fenzi
 
Default python26 note

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_type=al lwordssubstr&component=Package+Review&query_format =advanced

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-04-2010, 06:35 PM
Mathieu Baudier
 
Default python26 note

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_wsgi.html

python26-virtualenv
http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/repoview/python26-virtualenv.html

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-04-2010, 08:49 PM
Toshio Kuratomi
 
Default python26 note

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_wsgi.html
>
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-virtualenv.html
>
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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-05-2010, 12:46 AM
BJ Dierkes
 
Default python26 note

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_wsgi.html
>>
> 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



_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-05-2010, 06:34 AM
Mathieu Baudier
 
Default python26 note

> 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-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-05-2010, 06:00 PM
Toshio Kuratomi
 
Default python26 note

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_wsgi.html
> >>
> > 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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 03:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org