I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this?
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski orion@cora.nwra.com wrote:
I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this?
I think the Koji people would be interested in this, as it would help them in moving Koji to Python 3. They have a requirement for Koji to be able to run on EL6, so this could help unblock moving to Python 3.
On 08/24/2016 11:39 PM, Neal Gompa wrote:
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski orion@cora.nwra.com wrote:
I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this?
I think the Koji people would be interested in this, as it would help them in moving Koji to Python 3. They have a requirement for Koji to be able to run on EL6, so this could help unblock moving to Python 3.
I might be wrong, but I believe I have heard at Flock that Koji is actually trying to maintain support of EL5 still!
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that there are few packages available and adding them when the package already exists in RHEL requires creating a separate parent package in Fedora pkgdb.
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski orion@cora.nwra.com wrote:
I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this?
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com
python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@ lists.fedoraproject.org
"AL" == Avram Lubkin aviso@rockhopper.net writes:
AL> Definitely, but it runs into the same problem as 3.4 on EL7, the AL> fact that there are few packages available and adding them when the AL> package already exists in RHEL requires creating a separate parent AL> package in Fedora pkgdb.
Which is an annoying bit of process, but it would be quite possible to exempt those packages from needing package reviews. It needn't take that long.
- J<
Which is an annoying bit of process, but it would be quite possible to exempt those packages from needing package reviews. It needn't take that long.
Not needing reviews would help, but I wonder how hard it would be to make them children of python-PACKAGE. The main issue is the SRPM needs to have a different name so there is no conflict with the RHEL SRPM. That's easy to set in the spec file, but the build system requires the SRPM name to match the Fedora pkgdb and git names. Is it possible to define children, so python34-PACKAGE could use the same git repo as python-PACKAGE? This would be cleaner and more accurate than the current convention of creating a python3-PACKAGE git repo and pkgdb package.
Avram
"AL" == Avram Lubkin aviso@rockhopper.net writes:
AL> Not needing reviews would help, but I wonder how hard it would be to AL> make them children of python-PACKAGE. The main issue is the SRPM AL> needs to have a different name so there is no conflict with the RHEL AL> SRPM.
To be completely fair, I don't actually know EPEL policy here. The rule is that you can't conflict with RHEL packages, but SRPMs aren't really installed the same way as other packages and whether or not they would install to the same location depends somewhat on your personal .rpmrc.
It's probably been discussed somewhere and I just don't recall, but it's definitely worth asking someone who can answer properly.
- J<
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
To be completely fair, I don't actually know EPEL policy here. The rule is that you can't conflict with RHEL packages, but SRPMs aren't really installed the same way as other packages and whether or not they would install to the same location depends somewhat on your personal .rpmrc.
As far as I know, this is the adopted policy [1]. Though, I'm not sure if that was ever made official since it's still on a user page. I couldn't find anything that specifically says SRPM names can't be the same and it seems like that is not the process for additional architecture packages. [2] They just use a leading 0 in the release, ex: foobar-1.0-0.1.
I'm curious if anyone else has any insight. Maybe it is worth bringing up at a FPC meeting.
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_ Python3#Packaging_Parallel_python3X_stacks [2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
On 08/24/2016 11:38 PM, Orion Poplawski wrote:
I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this?
epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o...
Some software like BioPython will lose Python2.6 support in near future. Python34 support can be useful on epel6 provided that all related dependencies are available.
python-devel@lists.fedoraproject.org
-
Antonio Trande -
Avram Lubkin -
Jason L Tibbitts III -
Neal Gompa -
Orion Poplawski -
Tomas Orsava