It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there?
It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
On Tue, Jan 14, 2014 at 09:57:18AM -0700, Orion Poplawski wrote:
It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to
It may be very helpful to have Python 3 in EPEL-7. I'm planing to provide the current version of blender on EPEL-7 and this version requires Python 3.
Best Regards:
Jochen Schmitt
On 14 January 2014 09:57, Orion Poplawski orion@cora.nwra.com wrote:
It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there?
It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
Well a couple of other things would be needed beyond just maintenance:
1) Does providing python-3.4 mean that 3.4 will be the only python every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled?
On Tue, Jan 14, 2014 at 12:35:00PM -0700, Stephen John Smoogen wrote:
- Does providing python-3.4 mean that 3.4 will be the only python every
provided by EPEL?
On Fedora ew have a python package which points to the 2.7 series and a python3 package which points to the 3.3 series of python. I think we should take this solution for EPEL because I think that python-2.7.x is the standard python version which should not been overriden.
- If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
handled?
I think we need a conservative update handling to avoid incompatibilities caused due an python update.
Best Regards:
Jochen Schmitt
On Tue, Jan 14, 2014 at 09:13:12PM +0100, Jochen Schmitt wrote:
On Tue, Jan 14, 2014 at 12:35:00PM -0700, Stephen John Smoogen wrote:
- Does providing python-3.4 mean that 3.4 will be the only python every
provided by EPEL?
On Fedora ew have a python package which points to the 2.7 series and a python3 package which points to the 3.3 series of python. I think we should take this solution for EPEL because I think that python-2.7.x is the standard python version which should not been overriden.
- If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
handled?
I think we need a conservative update handling to avoid incompatibilities caused due an python update.
We could also take the python2.6 package in EPEL5 as inspiration here and ship a python3.4. This would allow us to ship a python3.5, python3.6, etc set of packages in the future.
-Toshio
----- Original Message -----
On 14 January 2014 09:57, Orion Poplawski < orion@cora.nwra.com > wrote:
It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to
maintain it there?
It seems to build fine:
http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
Well a couple of other things would be needed beyond just maintenance:
- Does providing python-3.4 mean that 3.4 will be the only python every
provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled?
-- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Slavek.
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/15/2014 02:16 AM, Bohuslav Kabrda wrote:
On 14 January 2014 09:57, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there?
It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
Well a couple of other things would be needed beyond just maintenance:
- Does providing python-3.4 mean that 3.4 will be the only python
every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled?
-- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Perhaps this would be a good time to reopen the conversation of minor-release policy changes?
RHEL releases approximately every six months with a minor release. It seems fair to allow major EPEL upgrades to occur in sync with those releases as well.
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
On Wed, Jan 15, 2014 at 8:32 AM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/15/2014 02:16 AM, Bohuslav Kabrda wrote:
On 14 January 2014 09:57, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there?
It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
Well a couple of other things would be needed beyond just maintenance:
- Does providing python-3.4 mean that 3.4 will be the only python
every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled?
-- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Perhaps this would be a good time to reopen the conversation of minor-release policy changes?
RHEL releases approximately every six months with a minor release. It seems fair to allow major EPEL upgrades to occur in sync with those releases as well.
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
My understanding is that RHEL minor release can include "major upgrades" to non-core parts (LibreOffice, Firefox, etc) but that core parts (the kernel, compiler, python version, etc) don't see "major upgrades". I personally like that model and think that it provides the stability needed for an enterprise class system, so I think that those same general guidelines should be upheld by the EPEL. If you really want/need the latest and greatest of everything all the time, then I believe that Fedora is probably a better fit than RHEL.
On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.
This would be a place to put e.g django-1.6.
In general: when allowing package upgrades, there might be manual steps required after package upgrade, like starting database migrations, tweaking config files to adjust to new syntax, etc. I'm not sure, if that is really acceptable.
Thoughts?
Matthias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/16/2014 04:08 AM, Matthias Runge wrote:
On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.
This would be a place to put e.g django-1.6.
In general: when allowing package upgrades, there might be manual steps required after package upgrade, like starting database migrations, tweaking config files to adjust to new syntax, etc. I'm not sure, if that is really acceptable.
In the case of Django, my experience has been that this is often required for even minor updates (see Review Board for examples). My solution there was to work with upstream to build tools to automatically manage these upgrades so they are invisible to the package consumer.
Thoughts?
Matthias
_______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Jan 16, 2014 1:08 AM, "Matthias Runge" mrunge@matthias-runge.de wrote:
On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.
This would be a place to put e.g django-1.6.
Although I would favor being able to deprecate one version of a package and introduce a newer incompatible version in some manner I have to point out here that if we "set some limits" to avoid breaking things then those limits would almost certainly cover frameworks and language stacks like python and django.
This is the basic problem that we inevitably face - people who have deployed software that relies on the old version inevitably do not want a new, incompatible version to appear in the reps that causes them to have to do extra porting work. People who have not yet deployed (or written) their software want the latest and greatest version of the software so they can build it using features provided by the latest version.
I think there's two classes of upgrade policy that we might implement to address this.
1) we think we have enough manpower in epel to support more packages. If this is the case then we should be looking at ways to support more than one version of packages on the repository. Ideas here include:
+ parallel versions (what we do today. Parallel installable Python3.3 and python3.4 packages are in this vein).
+ multiple versions that have explicit conflicts between them. Conflicts aren't allowed in fedora packages but this could be an epel difference.
2) we don't feel we have the manpower to support multiple versions. In this case we have to decide whether we are more strongly in favor of supporting existing deployments or supporting new deployments. Existing deployments is our default now. Our story for new deployments is that we must have parallel installable versions to make that use case work. Sgallagh's proposal turns that around so that we favour new deployments' needs more than existing ones. There are ways to improve it for existing deployments - for instance we could create a new repository for each of these point releases. Those repositories could be open or closed for new packages/updates depending on how much manpower we think we have to throw at the problem.
-Toshio
On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi a.badger@gmail.com wrote:
On Jan 16, 2014 1:08 AM, "Matthias Runge" mrunge@matthias-runge.de wrote:
On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.
This would be a place to put e.g django-1.6.
Although I would favor being able to deprecate one version of a package and introduce a newer incompatible version in some manner I have to point out here that if we "set some limits" to avoid breaking things then those limits would almost certainly cover frameworks and language stacks like python and django.
This is the basic problem that we inevitably face - people who have deployed software that relies on the old version inevitably do not want a new, incompatible version to appear in the reps that causes them to have to do extra porting work. People who have not yet deployed (or written) their software want the latest and greatest version of the software so they can build it using features provided by the latest version.
I think there's two classes of upgrade policy that we might implement to address this.
- we think we have enough manpower in epel to support more packages. If
this is the case then we should be looking at ways to support more than one version of packages on the repository. Ideas here include:
- parallel versions (what we do today. Parallel installable Python3.3 and
python3.4 packages are in this vein).
- multiple versions that have explicit conflicts between them. Conflicts
aren't allowed in fedora packages but this could be an epel difference.
- we don't feel we have the manpower to support multiple versions. In
this case we have to decide whether we are more strongly in favor of supporting existing deployments or supporting new deployments. Existing deployments is our default now. Our story for new deployments is that we must have parallel installable versions to make that use case work. Sgallagh's proposal turns that around so that we favour new deployments' needs more than existing ones. There are ways to improve it for existing deployments - for instance we could create a new repository for each of these point releases. Those repositories could be open or closed for new packages/updates depending on how much manpower we think we have to throw at the problem.
My personal vote would be for either the parallel versions of #1 so people aren't forced to upgrade or #2 with maintaining the priority for existing deployments. EL provides a known/stable base and I think that EPEL should maintain that same philosophy for at least the frameworks and language stacks.
Wouldn't this be a perfect use case for Software Collections?
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/...
-Dave
On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen davejohansen@gmail.comwrote:
On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi a.badger@gmail.comwrote:
On Jan 16, 2014 1:08 AM, "Matthias Runge" mrunge@matthias-runge.de wrote:
On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.
This would be a place to put e.g django-1.6.
Although I would favor being able to deprecate one version of a package and introduce a newer incompatible version in some manner I have to point out here that if we "set some limits" to avoid breaking things then those limits would almost certainly cover frameworks and language stacks like python and django.
This is the basic problem that we inevitably face - people who have deployed software that relies on the old version inevitably do not want a new, incompatible version to appear in the reps that causes them to have to do extra porting work. People who have not yet deployed (or written) their software want the latest and greatest version of the software so they can build it using features provided by the latest version.
I think there's two classes of upgrade policy that we might implement to address this.
- we think we have enough manpower in epel to support more packages. If
this is the case then we should be looking at ways to support more than one version of packages on the repository. Ideas here include:
- parallel versions (what we do today. Parallel installable Python3.3
and python3.4 packages are in this vein).
- multiple versions that have explicit conflicts between them. Conflicts
aren't allowed in fedora packages but this could be an epel difference.
- we don't feel we have the manpower to support multiple versions. In
this case we have to decide whether we are more strongly in favor of supporting existing deployments or supporting new deployments. Existing deployments is our default now. Our story for new deployments is that we must have parallel installable versions to make that use case work. Sgallagh's proposal turns that around so that we favour new deployments' needs more than existing ones. There are ways to improve it for existing deployments - for instance we could create a new repository for each of these point releases. Those repositories could be open or closed for new packages/updates depending on how much manpower we think we have to throw at the problem.
My personal vote would be for either the parallel versions of #1 so people aren't forced to upgrade or #2 with maintaining the priority for existing deployments. EL provides a known/stable base and I think that EPEL should maintain that same philosophy for at least the frameworks and language stacks.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote:
Wouldn't this be a perfect use case for Software Collections?
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/ Software_Collections_Guide/index.html
I was considering this earlier and I'm a bit conflicted about that. There's several problems with this. The most obvious is that SCLs are rather coarse grained and we want to solve this for both the coarse grained stuff like (python interpreter) and fine grained things (like upgrading a single library)
The second problem is that we don't just want these things for users to use. We also want them for our own use. But SCLs are meant to be isolated from the system.so we've mostly decided that things in the system shouldn't use SCLs to work. So we still need to solve the problem of newer python interpreter and newer django framework for use with apps that EPEL ships.
-Toshio
-Dave
On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen davejohansen@gmail.com wrote:
On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi <a.badger@gmail.com> wrote: On Jan 16, 2014 1:08 AM, "Matthias Runge" <mrunge@matthias-runge.de> wrote: > > On 01/15/2014 04:32 PM, Stephen Gallagher wrote: > > > > > So my suggestion would be that EPEL should have two branches for EPEL > > 7: the epel7 branch and the epel7-pending branch. The idea of this > > second branch would be sort of an EPEL Rawhide, where major upgrades > > can be staged. Then, when RHEL releases a minor update (such as RHEL > > 7.1), we have a (one-month?) integration period where we ensure that > > packages in epel7-pending work on the newest minor release and then > > they are merged back to epel7. If they miss this merge window, they > > have to wait until the next minor release. > > > > This allows us a regular, planned ability to move to newer EPEL > > packages, without destabilizing EPEL in general. > > > > In order to not make this a willy-nilly breakage every six months, we > > might want to set some limits (or at least guidelines) on what is or > > is not allowed to upgrade at the minor release. But I'd be fine with > > deferring making such decisions until we have a demonstrated need > > (i.e. fix it only if packages/EPEL is actually breaking). > Interesting idea, I like that. > > This would be a place to put e.g django-1.6. > Although I would favor being able to deprecate one version of a package and introduce a newer incompatible version in some manner I have to point out here that if we "set some limits" to avoid breaking things then those limits would almost certainly cover frameworks and language stacks like python and django. This is the basic problem that we inevitably face - people who have deployed software that relies on the old version inevitably do not want a new, incompatible version to appear in the reps that causes them to have to do extra porting work. People who have not yet deployed (or written) their software want the latest and greatest version of the software so they can build it using features provided by the latest version. I think there's two classes of upgrade policy that we might implement to address this. 1) we think we have enough manpower in epel to support more packages. If this is the case then we should be looking at ways to support more than one version of packages on the repository. Ideas here include: + parallel versions (what we do today. Parallel installable Python3.3 and python3.4 packages are in this vein). + multiple versions that have explicit conflicts between them. Conflicts aren't allowed in fedora packages but this could be an epel difference. 2) we don't feel we have the manpower to support multiple versions. In this case we have to decide whether we are more strongly in favor of supporting existing deployments or supporting new deployments. Existing deployments is our default now. Our story for new deployments is that we must have parallel installable versions to make that use case work. Sgallagh's proposal turns that around so that we favour new deployments' needs more than existing ones. There are ways to improve it for existing deployments - for instance we could create a new repository for each of these point releases. Those repositories could be open or closed for new packages/updates depending on how much manpower we think we have to throw at the problem. My personal vote would be for either the parallel versions of #1 so people aren't forced to upgrade or #2 with maintaining the priority for existing deployments. EL provides a known/stable base and I think that EPEL should maintain that same philosophy for at least the frameworks and language stacks. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Thu, Jan 16, 2014 at 6:28 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote:
Wouldn't this be a perfect use case for Software Collections?
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/
Software_Collections_Guide/index.html
I was considering this earlier and I'm a bit conflicted about that. There's several problems with this. The most obvious is that SCLs are rather coarse grained and we want to solve this for both the coarse grained stuff like (python interpreter) and fine grained things (like upgrading a single library)
The second problem is that we don't just want these things for users to use. We also want them for our own use. But SCLs are meant to be isolated from the system.so we've mostly decided that things in the system shouldn't use SCLs to work. So we still need to solve the problem of newer python interpreter and newer django framework for use with apps that EPEL ships.
What about having a separate EPEL repo for SCLs and/or these newest version of things? Like you mentioned before, this takes more work, but if then those that want the stable base can have it and those that want the newest can have it as well.
On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
system.so we've mostly decided that things in the system shouldn't use SCLs to work. So we still need to solve the problem of newer python interpreter and newer django framework for use with apps that EPEL ships.
What about having a separate EPEL repo for SCLs and/or these newest version of things? Like you mentioned before, this takes more work, but if then those that want the stable base can have it and those that want the newest can have it as well.
Or possibly an additional sub-project separate from EPEL. The idea has been kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra Packages for Infrastructure and Clouds, I think). I was thinking about this more recently in the context of "things we need for Fedora.next in the coming year or so". The new repo might target both EL and Fedora and provide alternative versions maintained on, say, a 3-year lifecycle.
On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote:
On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
system.so we've mostly decided that things in the system shouldn't use SCLs to work. So we still need to solve the problem of newer python interpreter and newer django framework for use with apps that EPEL ships.
What about having a separate EPEL repo for SCLs and/or these newest version of things? Like you mentioned before, this takes more work, but if then those that want the stable base can have it and those that want the newest can have it as well.
The problem I'm raising is that SCLs don't solve the problem that sgallagh is wanting to address by current policy. He has applications (ReviewBoard) that need newer versions of a framework (django) in order to run. For us to ship reviewboard in EPEL, we'd need to figure out if we want to allow that and how. Possible options are:
* ReviewBoard is in its own SCL. The SCL deps on the appropriate django SCL. * ReviewBoard is not in an SCL and we allow mainstream packages to dep on SCLs. We need to figure out guidance on how a package can enable an scl for its own use as well.
Either of these may exacerbate the problem of an enabled scl polluting other applications (especially hard if we get into invoking other processes from that application... env variables like LD_LIBRRY_PATH will probably get passed onto the invoked process).
Or possibly an additional sub-project separate from EPEL. The idea has been kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra Packages for Infrastructure and Clouds, I think). I was thinking about this more recently in the context of "things we need for Fedora.next in the coming year or so". The new repo might target both EL and Fedora and provide alternative versions maintained on, say, a 3-year lifecycle.
Yeah -- I think that something like this could be good. A repo with a 3 year lifecycle may make sense for RHEL more than Fedora as the basesystem we're building on is still active at the end of that period.
On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
Packages for Infrastructure and Clouds, I think). I was thinking about this more recently in the context of "things we need for Fedora.next in the coming year or so". The new repo might target both EL and Fedora and provide alternative versions maintained on, say, a 3-year lifecycle.
Yeah -- I think that something like this could be good. A repo with a 3 year lifecycle may make sense for RHEL more than Fedora as the basesystem we're building on is still active at the end of that period.
I'm thinking here about SCLs (or possibly other stack/env tech) that might target current supported Fedora but have a longer lifecyle of its own (with best-effort compatibility for three years).
I keep coming back to this idea because it's what people ask me for. :)
On Fri, Jan 17, 2014 at 01:57:18PM -0500, Matthew Miller wrote:
On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
Packages for Infrastructure and Clouds, I think). I was thinking about this more recently in the context of "things we need for Fedora.next in the coming year or so". The new repo might target both EL and Fedora and provide alternative versions maintained on, say, a 3-year lifecycle.
Yeah -- I think that something like this could be good. A repo with a 3 year lifecycle may make sense for RHEL more than Fedora as the basesystem we're building on is still active at the end of that period.
I'm thinking here about SCLs (or possibly other stack/env tech) that might target current supported Fedora but have a longer lifecyle of its own (with best-effort compatibility for three years).
I keep coming back to this idea because it's what people ask me for. :)
Ah I see. I think present thinking around SCLs has revolved around lifetime for indivudal SCLs but having a repository wide lifetime could be either better or a useful additional guarantee.
-Toshio
On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
Perhaps this would be a good time to reopen the conversation of minor-release policy changes?
Sure.
RHEL releases approximately every six months with a minor release. It seems fair to allow major EPEL upgrades to occur in sync with those releases as well.
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
ok, issues/thoughts:
* Another branch is a fair bit more work rel-eng and infra wise. Would they be completely seperate? How do we merge them at a update point?
ie, say I have foo. I have 1.0 in epel7 and push 1.2 to epel7-pending. Does the epel7-pending one use bodhi? Does it get signed and composed and push to a repo somewhere? now, say rhel7.1 comes out. How do we reconcile the two branches/trees/composes?
* The change point seems like it would be kinda fluid, which would not be great expectation wise. Ie, say rhel7.1 comes out. How long after that do we wait to push the changes? We can't really do it the same time, as we won't know for sure what that will be. We could do it as soon as it's public, but then enterprise rebuilds aren't ready yet. We could wait for CentOS, but then do we wait for SL? OEL? Do we tell users "it can happen some random time after a minor release, please pay attention"?
* The majority of epel packages I think don't care about this. It's only a subset. Perhaps we could do something with them? Move them to coprs, get them in as CentOS variants, something?
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Sure, agreed.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/16/2014 10:14 AM, Kevin Fenzi wrote:
On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
Perhaps this would be a good time to reopen the conversation of minor-release policy changes?
Sure.
RHEL releases approximately every six months with a minor release. It seems fair to allow major EPEL upgrades to occur in sync with those releases as well.
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
ok, issues/thoughts:
- Another branch is a fair bit more work rel-eng and infra wise.
Would they be completely seperate? How do we merge them at a update point?
ie, say I have foo. I have 1.0 in epel7 and push 1.2 to epel7-pending. Does the epel7-pending one use bodhi? Does it get signed and composed and push to a repo somewhere? now, say rhel7.1 comes out. How do we reconcile the two branches/trees/composes?
My thoughts are these (in no particular order). * Treat this branch like Rawhide. All builds targeted at this are composed to a repo. Signing is nice, but not mandatory in my opinion. * When rhel7.1 comes out, there is no automatic movement from epel7-pending into the epel branch. We open a merge window where packages are allowed to merge from the epel7-pending git branch. Merging a major upgrade outside this window is forbidden. At this time, any packager that believes their package is ready for prime-time may manually perform a merge, build and submission to Bodhi.
- The change point seems like it would be kinda fluid, which would
not be great expectation wise. Ie, say rhel7.1 comes out. How long after that do we wait to push the changes? We can't really do it the same time, as we won't know for sure what that will be. We could do it as soon as it's public, but then enterprise rebuilds aren't ready yet. We could wait for CentOS, but then do we wait for SL? OEL? Do we tell users "it can happen some random time after a minor release, please pay attention"?
I think we could set a policy of "merge window opens one week after official RHEL release and remains open for two/three weeks after that". Packages have to go through Bodhi approval for upgrade (perhaps we mandate at least one positive karma review on major upgrades?) which may take longer than the merge window, but they have to be submitted within that time.
- The majority of epel packages I think don't care about this.
It's only a subset. Perhaps we could do something with them? Move them to coprs, get them in as CentOS variants, something?
The majority isn't necessarily as interesting as the popular packages. There are plenty of people out there who want to see new Django, Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade in EPEL 6 today because they aren't fully backwards-compatible.
COPRs is really a workaround for (IMHO) a failure of policy in EPEL to remain useful as the world moves ahead. It's pretty unrealistic to expect volunteer package maintainers to support their packages for the same duration that Red Hat supports RHEL (currently ten years for RHEL 5 and 6). I think we're discouraging community inclusion if we don't offer people a policy that allows them to keep their package closer to upstream for reduced maintenance effort.
In order to not make this a willy-nilly breakage every six months, we might want to set some limits (or at least guidelines) on what is or is not allowed to upgrade at the minor release. But I'd be fine with deferring making such decisions until we have a demonstrated need (i.e. fix it only if packages/EPEL is actually breaking).
Sure, agreed.
kevin
On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/16/2014 10:14 AM, Kevin Fenzi wrote:
On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
Perhaps this would be a good time to reopen the conversation of minor-release policy changes?
Sure.
RHEL releases approximately every six months with a minor release. It seems fair to allow major EPEL upgrades to occur in sync with those releases as well.
So my suggestion would be that EPEL should have two branches for EPEL 7: the epel7 branch and the epel7-pending branch. The idea of this second branch would be sort of an EPEL Rawhide, where major upgrades can be staged. Then, when RHEL releases a minor update (such as RHEL 7.1), we have a (one-month?) integration period where we ensure that packages in epel7-pending work on the newest minor release and then they are merged back to epel7. If they miss this merge window, they have to wait until the next minor release.
This allows us a regular, planned ability to move to newer EPEL packages, without destabilizing EPEL in general.
ok, issues/thoughts:
- Another branch is a fair bit more work rel-eng and infra wise.
Would they be completely seperate? How do we merge them at a update point?
ie, say I have foo. I have 1.0 in epel7 and push 1.2 to epel7-pending. Does the epel7-pending one use bodhi? Does it get signed and composed and push to a repo somewhere? now, say rhel7.1 comes out. How do we reconcile the two branches/trees/composes?
My thoughts are these (in no particular order).
- Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
- When rhel7.1 comes out, there is no automatic movement from
epel7-pending into the epel branch. We open a merge window where packages are allowed to merge from the epel7-pending git branch. Merging a major upgrade outside this window is forbidden. At this time, any packager that believes their package is ready for prime-time may manually perform a merge, build and submission to Bodhi.
- The change point seems like it would be kinda fluid, which would
not be great expectation wise. Ie, say rhel7.1 comes out. How long after that do we wait to push the changes? We can't really do it the same time, as we won't know for sure what that will be. We could do it as soon as it's public, but then enterprise rebuilds aren't ready yet. We could wait for CentOS, but then do we wait for SL? OEL? Do we tell users "it can happen some random time after a minor release, please pay attention"?
I think we could set a policy of "merge window opens one week after official RHEL release and remains open for two/three weeks after that". Packages have to go through Bodhi approval for upgrade (perhaps we mandate at least one positive karma review on major upgrades?) which may take longer than the merge window, but they have to be submitted within that time.
- The majority of epel packages I think don't care about this.
It's only a subset. Perhaps we could do something with them? Move them to coprs, get them in as CentOS variants, something?
The majority isn't necessarily as interesting as the popular packages. There are plenty of people out there who want to see new Django, Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade in EPEL 6 today because they aren't fully backwards-compatible.
COPRs is really a workaround for (IMHO) a failure of policy in EPEL to remain useful as the world moves ahead. It's pretty unrealistic to expect volunteer package maintainers to support their packages for the same duration that Red Hat supports RHEL (currently ten years for RHEL 5 and 6). I think we're discouraging community inclusion if we don't offer people a policy that allows them to keep their package closer to upstream for reduced maintenance effort.
Yes, this makes the experience better for maintainers, but makes the experience worse for users and developers of existing tools/infrastructure. All the RHEL users I know choose it because they want a stable platform that isn't changing every 6 months to a year. Like Toshio mentioned before, existing projects want what's there to stay there and new projects want the latest and greatest. The EL mentality is "stable and predictable" and the Fedora mentality is "latest and greatest", so I think that both options are there for those that want them and I don't think that changing EL to be more Fedora like is a good thing.
On Fri, 17 Jan 2014 08:00:58 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
My thoughts are these (in no particular order).
- Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
It's pretty much impossible to sign rawhide style repos. ;)
- When rhel7.1 comes out, there is no automatic movement from
epel7-pending into the epel branch. We open a merge window where packages are allowed to merge from the epel7-pending git branch. Merging a major upgrade outside this window is forbidden. At this time, any packager that believes their package is ready for prime-time may manually perform a merge, build and submission to Bodhi.
ok. How long does the merge window last? Can people push to stable during this? Or everything stays in testing until the window closes?
I think we could set a policy of "merge window opens one week after official RHEL release and remains open for two/three weeks after that". Packages have to go through Bodhi approval for upgrade (perhaps we mandate at least one positive karma review on major upgrades?) which may take longer than the merge window, but they have to be submitted within that time.
This leaves people using enterprise linux rebuilds in a bad place since they don't have the new release to test with. Only once they have upgraded would they be able to be sure the packages are good for the new release.
This also means that many folks will delay the update on many of their machines (7.0->7.1) until the window is over and they can update epel stuff at the same time. Otherwise they have to schedule 2 big updates (the 7.0->7.1 and the epel merge window closing).
The majority isn't necessarily as interesting as the popular packages.
Well, it's like anything else... "I don't care about any packages except this specific ones that I really really care about" :)
There are plenty of people out there who want to see new Django, Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade in EPEL 6 today because they aren't fully backwards-compatible.
Well, Django is a interesting one... whats wrong with the forward compat packages there?
Install Django14 <wait until your apps all are able to work with 1.5> Update to Django15 and do the incompatible update lather, rinse, repeat.
I know, the pain there is the packaging...
COPRs is really a workaround for (IMHO) a failure of policy in EPEL to remain useful as the world moves ahead. It's pretty unrealistic to expect volunteer package maintainers to support their packages for the same duration that Red Hat supports RHEL (currently ten years for RHEL 5 and 6). I think we're discouraging community inclusion if we don't offer people a policy that allows them to keep their package closer to upstream for reduced maintenance effort.
Well, I think lots of people do find EPEL useful. I know I do.
It's a balancing act. Lots of different groups want different things. Additionally, it's hard to say what most EPEL consumers want because they aren't very vocal, they just consume. ;)
What about Toshios ideas of allowing conflicts:
We add a EPEL specific guideline that allows forward compat packages to NOT be parallel installable, as long as they conflict with the other versions of that package. Would that get us to a better place? That reduces the problems with making parallel installable compat packages, you simply need to adjust the names and pass review.
kevin
On Fri, Jan 17, 2014 at 03:42:34PM -0700, Kevin Fenzi wrote:
My thoughts are these (in no particular order).
- Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
It's pretty much impossible to sign rawhide style repos. ;)
I don't think that's the case. It does affect what sigificance / level of trust is attached to the signature, though. Signing which happens as part of the build process asserts that _this package came through our build system_. (And implicitly, that we think the build system isn't compromised.)
That's less of a strong guarantee than "a human inspected this package and asserts that ________", with _______ being whatever human verification is done. It's my undertand that right now, the signing process actually doesn't make a very strong assertion at all -- it is roughly "a human ran a script to take output from the area where the build system is expected to put it, and this is that output". Correct me if I'm wrong!
This is somewhat more secure than signing _in_ the build system because the signing key is more protected, but could potentially introduce another avenue of attack (between buildsystem output and signing). If the build system is compromised in a way that isn't detected, compromised output would likely get signed anyway, right? It's not much of a stronger assertion than the auto-signed one.
Doing anything much greater involves human time with each package, and that's really expensive. Since I don't think we are likely to get the funding to do that, and since being able to make the _basic_ assertion for all of our devel/rawhide packages would be quite valuable, I think we should aim for doing it. (Whether it should replace or just supplement the current signing process, I don't have a really strong opinion on, although I'm in general in favor of more automation and less work which depends on intervention from specially-privileged humans, because that can become a bottleneck.)
On Mon, 20 Jan 2014 09:11:48 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jan 17, 2014 at 03:42:34PM -0700, Kevin Fenzi wrote:
My thoughts are these (in no particular order).
- Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
It's pretty much impossible to sign rawhide style repos. ;)
...snip a bunch of stuff I agree with...
Yes, sorry I was unclear here.
It's pretty much impossible with our current signing setup to sign rawhide style repos. ;)
sigul has no ability to do non interactive signing. You always have to provide it with a passphrase with the list of things to sign.
There is a koji plugin to sign all built packages, but it stores gpg keys on the hub, passphrases in the koji config and is pretty much never going to be acceptable to upstream koji to add.
Ideally we would have someone able to improve sigul so we could do some kind of unattended signing in specific cases (and lock that down as much as we can). Currently we don't have this. ;)
kevin
On Mon, Jan 20, 2014 at 10:49:07AM -0700, Kevin Fenzi wrote:
It's pretty much impossible with our current signing setup to sign rawhide style repos. ;)
Ah, okay. Glad to have misunderstood there. :)
There is a koji plugin to sign all built packages, but it stores gpg keys on the hub, passphrases in the koji config and is pretty much never going to be acceptable to upstream koji to add.
Maybe an intermediate thing would be a less-secure-than-sigil-but-still- separate automatic signing server?
On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
On 14 January 2014 09:57, Orion Poplawski <orion@cora.nwra.com <mailto:orion@cora.nwra.com>> wrote: It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there? It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/ Well a couple of other things would be needed beyond just maintenance: 1) Does providing python-3.4 mean that 3.4 will be the only python every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled? -- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Slavek.
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
Well, quite frankly, I think anyone expecting 10 years of support for EPEL packages is deluding themselves, some specific packages excepted. Users of EPEL are probably best served by upgrading to newer versions of EL as soon as practical.
My recommendation would be to ship python 3.4 as a "normal" python3 package. The python folks appear to be committed to providing 5 years of security fixes for a release. This seems to be as long can be reasonably expected of EPEL.
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.
On 01/15/2014 04:26 PM, Orion Poplawski wrote:
On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
On 14 January 2014 09:57, Orion Poplawski <orion@cora.nwra.com <mailto:orion@cora.nwra.com>> wrote: It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there? It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/ Well a couple of other things would be needed beyond just maintenance: 1) Does providing python-3.4 mean that 3.4 will be the only python every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled? -- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Slavek.
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
Well, quite frankly, I think anyone expecting 10 years of support for EPEL packages is deluding themselves, some specific packages excepted. Users of EPEL are probably best served by upgrading to newer versions of EL as soon as practical.
My recommendation would be to ship python 3.4 as a "normal" python3 package. The python folks appear to be committed to providing 5 years of security fixes for a release. This seems to be as long can be reasonably expected of EPEL.
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.
This thread appears to have gone off on a lot of tangents. Getting back to the original questions:
- Shall we build python 3.4 as python3 in EPEL7 when it is released? - Anyone willing to maintain it? - I see that 3.4.0 beta 2 is out, time to get it into rawhide at least?
Thanks.
----- Original Message -----
On 01/15/2014 04:26 PM, Orion Poplawski wrote:
On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
On 14 January 2014 09:57, Orion Poplawski <orion@cora.nwra.com <mailto:orion@cora.nwra.com>> wrote: It seems like it would be nice to have python 3 in EPEL 7. Anyone willing to maintain it there? It seems to build fine: http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/ Well a couple of other things would be needed beyond just maintenance: 1) Does providing python-3.4 mean that 3.4 will be the only python every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled? -- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Slavek.
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
Well, quite frankly, I think anyone expecting 10 years of support for EPEL packages is deluding themselves, some specific packages excepted. Users of EPEL are probably best served by upgrading to newer versions of EL as soon as practical.
My recommendation would be to ship python 3.4 as a "normal" python3 package. The python folks appear to be committed to providing 5 years of security fixes for a release. This seems to be as long can be reasonably expected of EPEL.
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.
This thread appears to have gone off on a lot of tangents. Getting back to the original questions:
- Shall we build python 3.4 as python3 in EPEL7 when it is released?
- Anyone willing to maintain it?
As I've noted previously, I won't stand in anyone's way, but I'm not going to maintain Python 3 in EPEL 7 myself.
- I see that 3.4.0 beta 2 is out, time to get it into rawhide at least?
There is a Change proposal for that at [1] and it's a work in progress. The thing that is holding me back is handling the ensurepip script. I already have an experimental solution, but I have to verify that it works under all possible circumstances, first. Also, the Change states that I'll build 3.4 for Rawhide only if "reasonably small amount of non-essential packages doesn't build/work with Python 3.4", which I haven't had time to test so far.
Thanks.
Slavek.
On 01/21/2014 11:50 PM, Bohuslav Kabrda wrote:
----- Original Message -----
On 01/15/2014 04:26 PM, Orion Poplawski wrote:
On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
Well a couple of other things would be needed beyond just maintenance: 1) Does providing python-3.4 mean that 3.4 will be the only python every provided by EPEL? 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be handled? -- Stephen J Smoogen.
Well the problem is that once you provide a build for EPEL, you shouldn't really do major updates [1], so it seems we would be stuck with whatever we build for 10+ years. I don't like that very much. We could probably do python3.4, python3.5 etc, but that'd probably require some modifications to dependency generators, etc... I'm not going to stay in anyones way to do this, but I won't do it myself.
Slavek.
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
Well, quite frankly, I think anyone expecting 10 years of support for EPEL packages is deluding themselves, some specific packages excepted. Users of EPEL are probably best served by upgrading to newer versions of EL as soon as practical.
My recommendation would be to ship python 3.4 as a "normal" python3 package. The python folks appear to be committed to providing 5 years of security fixes for a release. This seems to be as long can be reasonably expected of EPEL.
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4. This wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
- I looks like RedHat has been producing python33 SCLs, and presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
- Orion
On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski orion@cora.nwra.com wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4. This
wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and presumably
will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2014 10:53 AM, Kevin Fenzi wrote:
On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski orion@cora.nwra.com wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4.
This wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and
presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
Any further thoughts on this? I *think* with either python3 as 3.4 or python34 providing python3 = 3.4 you could later ship python35 providing 3.5, but perhaps it would be cleaner to start with python34. I confess to being lazy and not wanting to submit a new python34 package for review and have to maintain it in a separate git repo.
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x... of python3 actually using it (it seems to be using gdbm instead).
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6783089
- -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
We use both EPEL and SCL in my org. I didn't see this addressed in the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
Sent from my iPhone
On Apr 26, 2014, at 11:37 AM, Orion Poplawski orion@cora.nwra.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2014 10:53 AM, Kevin Fenzi wrote: On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski orion@cora.nwra.com wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4.
This wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and
presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
Any further thoughts on this? I *think* with either python3 as 3.4 or python34 providing python3 = 3.4 you could later ship python35 providing 3.5, but perhaps it would be cleaner to start with python34. I confess to being lazy and not wanting to submit a new python34 package for review and have to maintain it in a separate git repo.
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x... of python3 actually using it (it seems to be using gdbm instead).
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6783089
Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNb0pgACgkQORnzrtFC2/s0UQCgnsD8R7nA9jSP4xrRuXDCL3yV nCsAnRjXZxDJ4xyU9Iez9C/mVWcAg4hT =i+E9 -----END PGP SIGNATURE----- _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Apr 26, 2014 8:27 PM, "Aaron Knister" aaron.knister@gmail.com wrote:
We use both EPEL and SCL in my org. I didn't see this addressed in the
email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.
-Toshio
On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Apr 26, 2014 8:27 PM, "Aaron Knister" aaron.knister@gmail.com wrote:
We use both EPEL and SCL in my org. I didn't see this addressed in the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.
-Toshio
The contents are namespaced but the package names are not. We'll end up with a package called python34 in each repo that are incompatible. The SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL package will have a prefix of /. Undoubtedly there will be packages in EPEL (that aren't simply python34) modules that will require python34 that we'll be unable to use on systems with SCL because of the python34 package conflict. I wish RHEL had prefixed the package names with scl- but alas they did not.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Apr 27, 2014 9:37 AM, "Aaron Knister" aaron.knister@gmail.com wrote:
On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Apr 26, 2014 8:27 PM, "Aaron Knister" aaron.knister@gmail.com wrote:
We use both EPEL and SCL in my org. I didn't see this addressed in the
email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
If red hat does the right thing and namespaces their scl packages then
there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.
-Toshio
The contents are namespaced but the package names are not. We'll end up
with a package called python34 in each repo that are incompatible.
Exactly. That's why red hat has to do the right thing.
-Toshio
On 04/27/2014 07:37 AM, Aaron Knister wrote:
On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi <a.badger@gmail.com mailto:a.badger@gmail.com> wrote:
On Apr 26, 2014 8:27 PM, "Aaron Knister" <aaron.knister@gmail.com mailto:aaron.knister@gmail.com> wrote:
We use both EPEL and SCL in my org. I didn't see this addressed in
the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.
-Toshio
The contents are namespaced but the package names are not. We'll end up with a package called python34 in each repo that are incompatible. The SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL package will have a prefix of /. Undoubtedly there will be packages in EPEL (that aren't simply python34) modules that will require python34 that we'll be unable to use on systems with SCL because of the python34 package conflict. I wish RHEL had prefixed the package names with scl- but alas they did not.
What a pain. FWIW:
SCL 1.1: # repoquery --whatprovides python3 # repoquery --provides python33 python33 = 1.1-11.el7 python33(x86-64) = 1.1-11.el7 [root@vmrhel7 ~]# repoquery --provides python33-python python33-python = 3.3.2-10.el7 python33-python(abi) = 3.3 python33-python(x86-64) = 3.3.2-10.el7
EPEL7 (as currently conceived): # repoquery --provides python34 python(abi) = 3.4 python3 = 3.4.0-2.el7 python34 = 3.4.0-2.el7 python34(x86-64) = 3.4.0-2.el7
So yes, we'll likely conflict on the python34 name when python34 appears in SCL. The EPEL packages will likely simply require python(abi) = 3.4 and python3, so that may not be an issue.
I suppose we could use "python3.4".
I think it's a little unrealistic to expect the vendor to namespace their packages although it would be nice and probably the right thing to do. Could EPEL, as the 3rd-party layered product, namespace theirs? (e.g. epel-python34). It's more consistent with how other packages store version numbers in the name (although as an aside, the smushing together of version numbers without dots drives me a little crazy so part of me likes the dot in python3.4).
On Sun, Apr 27, 2014 at 3:49 PM, Orion Poplawski orion@cora.nwra.comwrote:
On 04/27/2014 07:37 AM, Aaron Knister wrote:
On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi <a.badger@gmail.com mailto:a.badger@gmail.com> wrote:
On Apr 26, 2014 8:27 PM, "Aaron Knister" <aaron.knister@gmail.com mailto:aaron.knister@gmail.com> wrote:
We use both EPEL and SCL in my org. I didn't see this addressed in
the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.
-Toshio
The contents are namespaced but the package names are not. We'll end up with a package called python34 in each repo that are incompatible. The SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL package will have a prefix of /. Undoubtedly there will be packages in EPEL (that aren't simply python34) modules that will require python34 that we'll be unable to use on systems with SCL because of the python34 package conflict. I wish RHEL had prefixed the package names with scl- but alas they did not.
What a pain. FWIW:
SCL 1.1: # repoquery --whatprovides python3 # repoquery --provides python33 python33 = 1.1-11.el7 python33(x86-64) = 1.1-11.el7 [root@vmrhel7 ~]# repoquery --provides python33-python python33-python = 3.3.2-10.el7 python33-python(abi) = 3.3 python33-python(x86-64) = 3.3.2-10.el7
EPEL7 (as currently conceived): # repoquery --provides python34 python(abi) = 3.4 python3 = 3.4.0-2.el7 python34 = 3.4.0-2.el7 python34(x86-64) = 3.4.0-2.el7
So yes, we'll likely conflict on the python34 name when python34 appears in SCL. The EPEL packages will likely simply require python(abi) = 3.4 and python3, so that may not be an issue.
I suppose we could use "python3.4".
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Mon, Apr 28, 2014 at 01:45:52PM -0400, Aaron Knister wrote:
I think it's a little unrealistic to expect the vendor to namespace their packages although it would be nice and probably the right thing to do.
If you buy from Red Hat, you should complain to them. That might have more effect than I have had.
Could EPEL, as the 3rd-party layered product, namespace theirs? (e.g. epel-python34). It's more consistent with how other packages store version numbers in the name
Unfortunately, this wouldn't be very consistent with the packages as a whole. If you have a bug in the python3 package that's in /usr/bin/python3.4, for instance, you're going to go to bugzilla looking to file against the python34 package, not epel-python34. And we'd be doing this for packages that we don't even build against or assume that people have. We also have no control over what packages Red Hat will choose to scl-ize. In the future, they could create mediawiki119 scls or Turbogears2 scls. So we really need Red Hat to stick to convention and not pollute the toplevel package
(although as an aside, the smushing together of version numbers without dots drives me a little crazy so part of me likes the dot in python3.4).
I also like the dot in the version number in the name. However, although that solves the problem of conflicting package names for a computer, it doesn't solve the problem for humans. (Why do I have both python3.4 and python34 packages installed? I should be able to get rid of one of those.) It's also not a requirement of scls that they do not contain any dots in the scl name. Future Red Hat supplied scls may put a dot into the name and thus we'll still have conflicts.
-Toshio
On Apr 26, 2014 11:37 AM, "Orion Poplawski" orion@cora.nwra.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2014 10:53 AM, Kevin Fenzi wrote:
On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski orion@cora.nwra.com wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4.
This wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and
presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
Any further thoughts on this? I *think* with either python3 as 3.4 or python34 providing python3 = 3.4 you could later ship python35 providing 3.5, but perhaps it would be cleaner to start with python34. I confess to being lazy and not wanting to submit a new python34 package for review and have to maintain it in a separate git repo.
I'm on vacation for a few days longer (fly home on Monday).
I'd like to see us do a python3.4-3.4.x and then python3.5-3.5.x, etc. But that's motivated by not wanting to maintain a specific python3 package for the life of rhel/epel. I'd rather we maintain two major versions at any one time so that people have a chance to transition their code but also limiting how many versions we'd have to maintain by rhel eol.
The versioning scheme would be similar to the mediawiki packages in epel for this scheme.
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in
http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x...
of python3 actually using it (it seems to be using gdbm instead).
Python 3 does use libdb although I think it can use libdb5. Python has a standard library that includes both libdb bindings and gdbm bindings.
(note, I likely won't reply again until tuesday when I get back from vacation but please feel free to ping me on irc or send email to get my attention then. I want to achieve similar end goals as you, I'm just busy doing vacation-y, non-internet things until then.)
-Toshio
On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
On Apr 26, 2014 11:37 AM, "Orion Poplawski" <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2014 10:53 AM, Kevin Fenzi wrote:
On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4.
This wou>>>
> Perhaps as time goes by, it may make sense to package a > later python3.X version if people really want to.ld allow > us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and
presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
Any further thoughts on this? I *think* with either python3 as 3.4 or python34 providing python3 = 3.4 you could later ship python35 providing 3.5, but perhaps it would be cleaner to start with python34. I confess to being lazy and not wanting to submit a new python34 package for review and have to maintain it in a separate git repo.
I'm on vacation for a few days longer (fly home on Monday).
I'd like to see us do a python3.4-3.4.x and then python3.5-3.5.x, etc. But that's motivated by not wanting to maintain a specific python3 package for the life of rhel/epel. I'd rather we maintain two major versions at any one time so that people have a chance to transition their code but also limiting how many versions we'd have to maintain by rhel eol.
The versioning scheme would be similar to the mediawiki packages in epel for this scheme.
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in
http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x...
of python3 actually using it (it seems to be using gdbm instead).
Python 3 does use libdb although I think it can use libdb5. Python has a standard library that includes both libdb bindings and gdbm bindings.
Hmm, I see no evidence that it makes use of both as currently built. It seems that gdbm is preferred and there are no dependencies on libdb*.
-Toshio
Submitted a python34 review here (I'm assuming that the 34 naming is still preferred over 3.4?):
https://bugzilla.redhat.com/show_bug.cgi?id=1091657
hopefully others will step up as co-maintainers.
On Sat, Apr 26, 2014 at 09:13:12PM -0600, Orion Poplawski wrote:
On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
On Apr 26, 2014 11:37 AM, "Orion Poplawski" <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in
http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x...
of python3 actually using it (it seems to be using gdbm instead).
Python 3 does use libdb although I think it can use libdb5. Python has a standard library that includes both libdb bindings and gdbm bindings.
Hmm, I see no evidence that it makes use of both as currently built. It seems that gdbm is preferred and there are no dependencies on libdb*.
On further investigation, I see that you are absolutely right. The bsddb module was removed from python3.0 so we can remove the BuildRequires on db for any python3 packages.
See the disclaimer at the top of the python2 docs: https://docs.python.org/2/library/bsddb.html
and the PEP: http://legacy.python.org/dev/peps/pep-3108/#maintenance-burden
-Toshio
epel-devel@lists.fedoraproject.org