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.
Created attachment 497376 [details] py26 patch
adding dependency on 700667
python26- packages are maintained separately from the main python- packages. Please submit a new python26- package review.
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?
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
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).
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
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.
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.
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.
That makes sense to me. Thanks for explaining that, Toshio. I wonder if the wiki should reflect that somewhere...
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.