Bittorrent Broken on FC4? (tricks for rpm packaging with flexible dependence?)

[Stuart Levy]

On Mon, 3 Oct 2005 16:29:25 -0600, Charles Curley wrote:
> Subject: Re: Bittorrent Broken on FC4?
> To: For users of Fedora Core releases <fedora-list at redhat.com>
> 
> On Mon, Oct 03, 2005 at 04:42:55PM -0500, Jason L Tibbitts III wrote:
> > >>>>> "CC" == Charles Curley <charlescurley at charlescurley.com> writes:
> > 
> > CC> I was running bittorrent (BitTorrent-4.0.2-1.noarch.rpm) find on
> > CC> FC3. I have installed FC4, and installed
> > CC> BitTorrent-4.0.4-1.noarch.rpm. I now get:
> > 
> > The packages in Extras are named bittorrent-4.0.4-1.fc4.noarch.rpm and
> > bittorrent-gui-4.0.4-1.fc4.noarch.rpm.  I suggest you uninstall
> > whatever packages you have, install the version from Extras, and then
> > report problems at bugzilla.redhat.com.
> 
> Thanks
> 
> I uninstalled the ones from bittorrent.com and installed those from
> extras. Problem solved. So I think it's a bt.com issue. I see no way
> to report the problem on bt.com.
> 
> I won't bugzilla it, as I don't think it's an FC issue.


I'll bet it's a question of python version number.
The stock bittorrent rpms install their stuff under
  /usr/lib/python<version>/site-packages/BitTorrent/...
But <version> is a moving target -- 2.2, 2.3, now FC4 uses python 2.4.
If the system's python version doesn't match the one used by
whoever packaged the bittorrent rpm, the modules get installed in a place
where python doesn't look for them.

Is there a better way that the bittorrent packagers could have
done this that doesn't require tying their rpm bundles to
particular Fedora releases?

Given that I suppose it's not dependent on bleeding-edge
python features, making bittorrent version X.Y depend on
python 2.Z seems uncomfortably inflexible.  Should bittorrent
put its modules in some convenient spot, then use a post-install
script to move them to the site-packages directory for the system's
installed version of python?