I'm packaging pymtp, which the new gPodder versions need as a
dependency. The review request is at
<https://bugzilla.redhat.com/show_bug.cgi?id=643199>. It's a python
binding to libmtp done with ctypes. The package in itself is noarch, but
I noticed it won't work, if the 32-bit version of libmtp is installed on
a 64-bit system.
Should I make the pymtp package arch dependent and require the libmtp
package, which matches the arch? Or should I require "libmtp" and trust
yum to install the 64-bit package on x86_64? That wouldn't solve the
case where the system already has the 32-bit libmtp installed, though.
Toshio Kuratomi wrote:
> If you're on packaging(a)lists.fp.o, we should probably take discussion
> Here's the fpc ticket with the question of whether we should relax the
> Note that your description of the rubygem-passenger system could still fail
> to pass the test under revised guidelines depending on what they turn out
> to be. For instance, the guidelines might allow bundling of the latest
> upstream version or of the version provided by Fedora, or they might
> require that the package maintainer be able to code fixes should they be
> necessary. It's probably a good idea to join packaging(a)lists.fp.o and
> give reasons that requirements like that aren't needed.
As per the thread on advisory-board;
I urge you to consider to allow exceptions like these for the greater benefit
of your users -and thus upstream, through Fedora.
Jeroen van Meeuwen