Bug 702677 - Add python26-paramiko subpackage to python-paramiko in EPEL5
Summary: Add python26-paramiko subpackage to python-paramiko in EPEL5
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-paramiko
Version: el5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 700667
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-06 14:55 UTC by Andy Grimm
Modified: 2016-11-08 03:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-09 23:56:04 UTC


Attachments (Terms of Use)
py26 patch (3.44 KB, patch)
2011-05-06 14:55 UTC, Andy Grimm
no flags Details | Diff

Description Andy Grimm 2011-05-06 14:55:04 UTC
It would be useful to have paramiko for python 2.6 in EPEL 5.  This requires having python26-crypto, which is in progress (see bz 700667).  I have attached a patch here to be reviewed.

Comment 1 Andy Grimm 2011-05-06 14:55:55 UTC
Created attachment 497376 [details]
py26 patch

Comment 2 Andy Grimm 2011-05-06 16:16:49 UTC
adding dependency on 700667

Comment 3 Toshio Ernie Kuratomi 2011-05-06 22:27:33 UTC
python26- packages are maintained separately from the main python- packages.  Please submit a new python26- package review.

Comment 4 Andy Grimm 2011-05-07 03:39:30 UTC
This is contradictory to the advice I was given in bz 700667, where Spot said, "Is it practical to carry this as a separate package? Given that the version and
code is identical, perhaps this could be added ... as a subpackage, much in the same way that same python3 packages are generated."
Is there a practical reason for maintaining them separately in this case?

Comment 5 Garrett Holmstrom 2011-05-07 04:11:13 UTC
There is precedence for building the same sources for multiple Python stacks in the same SRPM.  If the code works correctly that way then the choice of whether or not to maintain the alternate stack's package separately from the main one is up to the maintainer of the main package.

[1] http://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs

Comment 6 Tom "spot" Callaway 2011-05-09 17:30:43 UTC
So, yeah, I would say this is up to the maintainer of python-paramiko (assuming that package is in EPEL as opposed to RHEL base).

Comment 7 Gwyn Ciesla 2011-05-09 18:17:01 UTC
Either's fine with me, I see no reason not to subpackage it.  It fact, the guidelines seem to indicate that:

https://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs

Comment 8 Toshio Ernie Kuratomi 2011-05-09 23:56:04 UTC
No.  when dmalcolm worked on python26 I made sure that we discussed this and decided that python26 packages should be separate packages from the main pyhton-* packages.

There are two big reasons for this:

1) Keeping the package running with multiple versions of python can cause problems that force a package to get stuck on an old version.  For instance, python-docutils in F15 won't rebuild against python3.2.  This has lead to broken deps and the inability to ship newer versions of python-docutils for python2 despite there being nothing wrong with the python2 package, just hte python3 subpackage.

2) In EPEL especially, where a package has to keep compatibility once we release it into the repositories, creating a new package is an opportunity rather than a detriment.  Most people who are using RHEL but have the luxury of upgrading to python26 packages will want newer versions of the libraries that run on top of python26 as well.  Using the old version of the library because you're building as a subpackage is a disservice to the people using the library in their own projects.

Comment 9 Andy Grimm 2011-05-10 00:42:00 UTC
In the case of paramiko, I don't think that either of your "big reasons" are valid, but I am happy to follow the path of least resistance here.  I'll go back to building it as a separate package.

Comment 10 Gwyn Ciesla 2011-05-10 12:11:08 UTC
I agree with 1. and 2. especially in an EPEL context.  If you want me to help co-maintain the 26 package, let me know.

Comment 11 Garrett Holmstrom 2011-05-11 04:02:47 UTC
That makes sense to me.  Thanks for explaining that, Toshio.  I wonder if the wiki should reflect that somewhere...

Comment 12 Andy Grimm 2011-05-11 10:29:27 UTC
Upon rereading this, I need to apologize for the tone of my previous comment.  I do appreciate the explanation, but it does make me wonder why the package guidelines suggest the subpackaging approach at all.  I may start an email thread about it; no need to continue the conversation here.


Note You need to log in before you can comment on or make changes to this bug.