Neal Becker wrote:
Paul Howarth wrote:
Neal Becker wrote:
Jeremy Katz wrote:
Neal Becker wrote:
What should I do about this?
qct-mercurial.noarch: E:
noarch-python-in-64bit-path
/usr/lib64/python2.5/site-packages/hgext/qct.pyc
I think qct.py needs to go there, because that's where mercurial is
going to
look. As we discussed before, our multi-arch python is somewhat
broken, because you cannot have both /usr/lib/python/.../some_package
and /usr/lib64/python/.../some_package. It will only search one of
those
locations. So we cannot have both arch and nonarch site-packages/hgext
- unless maybe I'm misunderstanding something?
If it needs to be in the arch-specific path, the package needs to be
built for the native arch and not noarch
Jeremy
So qct will build 2 packages, a no-arch qct and an arch qct-mercurial, is
that correct?
Can anyone point me to an example of an rpm spec file that does this, I'm
not sure of the syntax?
Just build the whole lot as arch packages; all of the python-twisted-*
stack (which is mostly noarch) is built as arch-specific packages for
this reason.
Paul.
This will trigger:
rpmlint RPM/RPMS/x86_64/qct-1.5-4.fc8.x86_64.rpm
qct.x86_64: E: no-binary
I believe this is ignorable?
Yes, 'cause there's a good reason for it in this case.
Paul.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
