Moving the discussion to fedora-packaging as if even memebers of the packaging committee are confused and gove wrong advice, then this is something that should be discussed and placed into the packaging guidelines.
On Sat, Sep 02, 2006 at 11:09:22AM -0400, Jesse Keating wrote:
On Sat, 2006-09-02 at 17:08 +0200, Axel Thimm wrote:
On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote:
Due to the way that python works, if any part of a python's module is arch specific (sitearch), the entire thing has to go into sitearch. Python will not import part from sitearch and part from sitelib. So it'd all have to go in sitearch.
That's wrong.
Oh? Care to expand upon this?
If you have a module, importable module that is, has an __init.py__ and all that, if you shove part of it in sitearch and part of it in sitelib, it won't work. Is this statement wrong? If so, please do explain.
You mean just the way python-elementtree (and thus yum) works exactly that way since FC3?
Yes, that statement is wrong, just log onto a multilib system and check ownership of parts of sitelib. For example on FC5/x86_64:
# rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm\n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64 aqbanking-1.8.1beta-3.1.x86_64.rpm audit-libs-python-1.1.5-1.x86_64.rpm avahi-tools-0.6.10-1.FC5.x86_64.rpm python-elementtree-1.2.6-4.2.1.x86_64.rpm wireshark-0.99.2-fc5.2.x86_64.rpm
On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote:
You mean just the way python-elementtree (and thus yum) works exactly that way since FC3?
Yes, that statement is wrong, just log onto a multilib system and check ownership of parts of sitelib. For example on FC5/x86_64:
I think we're confusing the point. If the binary blob is part of the python module that won't work. Lets look at your examples:
# rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm \n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64 aqbanking-1.8.1beta-3.1.x86_64.rpm
Only arch specific stuff is in %{_libdir}/aqbanking/ %{_libdir}/gwenhywfar/ and %{_libdir} itself. There are no python modules that span both python sitearch and sitelib.
audit-libs-python-1.1.5-1.x86_64.rpm
This one is strange, has /usr/lib/python2.4/site-packages/audit.py AND /usr/lib64/python2.4/site-packages/_audit.so, not exactly sure whats going on there...
avahi-tools-0.6.10-1.FC5.x86_64.rpm
Only has python content in /usr/lib/python2.4/site-packages/avahi, no /usr/lib64 python content.
python-elementtree-1.2.6-4.2.1.x86_64.rpm
Has two different modules.
/usr/lib/python2.4/site-packages/elementtree/ being the 'elementtree' module and /usr/lib64/python2.4/site-packages/cElementTree.so being the 'cElementTree' module. Again no mixed locations for the same module.
wireshark-0.99.2-fc5.2.x86_64.rpm
Once again, the only python content is in /usr/lib/python2.4/site-packages/, no python content in /usr/lib64.
So I fail to see how these serve as any kind of example.
Stripped off quote from Jesse Keating:
Due to the way that python works, if any part of a python's module is arch specific (sitearch), the entire thing has to go into sitearch.
On Sat, Sep 02, 2006 at 11:37:54AM -0400, Jesse Keating wrote:
On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote:
You mean just the way python-elementtree (and thus yum) works exactly that way since FC3?
Yes, that statement is wrong, just log onto a multilib system and check ownership of parts of sitelib. For example on FC5/x86_64:
[ examples of packages having parts in both siteliba and sitearch ]
[ Jesse trying to justify why these packages do so ]
So I fail to see how these serve as any kind of example.
Just check your statement again. You outruled coexistence of python modules in both lib and lib64 and there are real-life counterexamples to that. What's more to not see???
On Sat, 2006-09-02 at 17:47 +0200, Axel Thimm wrote:
Just check your statement again. You outruled coexistence of python modules in both lib and lib64 and there are real-life counterexamples to that. What's more to not see???
Again I think we're talking past each other. I'm saying that a single python's module can't _both_ be in /usr/lib and /usr/lib64 at the SAME TIME. You can't have
/usr/lib/python2.4/site-packages/yum and /usr/lib64/python2.4/site-packages/yum
especially with different contents in each. Is what I'm saying clear now?
On Sat, Sep 02, 2006 at 11:52:27AM -0400, Jesse Keating wrote:
On Sat, 2006-09-02 at 17:47 +0200, Axel Thimm wrote:
Just check your statement again. You outruled coexistence of python modules in both lib and lib64 and there are real-life counterexamples to that. What's more to not see???
Again I think we're talking past each other. I'm saying that a single python's module can't _both_ be in /usr/lib and /usr/lib64 at the SAME TIME. You can't have
/usr/lib/python2.4/site-packages/yum and /usr/lib64/python2.4/site-packages/yum
especially with different contents in each. Is what I'm saying clear now?
I agree with the above, but that was not what you were saying. I won't bother copying your quote back again, you seem to have a reason why you're trimming it ;)
On Sat, 2006-09-02 at 18:04 +0200, Axel Thimm wrote:
I agree with the above, but that was not what you were saying. I won't bother copying your quote back again, you seem to have a reason why you're trimming it ;)
Please. Tell me what is wrong with:
Due to the way that python works, if any part of a python's module is arch specific (sitearch), the entire thing has to go into sitearch. Python will not import part from sitearch and part from sitelib. So it'd all have to go in sitearch.
Maybe my English isn't clear enough to you? "any part of a python's module", so we're talking about a single module here right? "is arch specific", pretty clear. "the entire thing", thing being the module. "has to go into sitearch", correct, has to go into the arch specific dir. Be that /usr/lib in i386 or /usr/lib64 on x86_64. Please, tell me where I'm failing English here, as it is my native language and I'd really like to know.
On Sat, Sep 02, 2006 at 12:13:41PM -0400, Jesse Keating wrote:
On Sat, 2006-09-02 at 18:04 +0200, Axel Thimm wrote:
I agree with the above, but that was not what you were saying. I won't bother copying your quote back again, you seem to have a reason why you're trimming it ;)
Please. Tell me what is wrong with:
Due to the way that python works, if any part of a python's module is arch specific (sitearch), the entire thing has to go into sitearch. Python will not import part from sitearch and part from sitelib. So it'd all have to go in sitearch.
Maybe my English isn't clear enough to you? "any part of a python's module", so we're talking about a single module here right? "is arch specific", pretty clear. "the entire thing", thing being the module. "has to go into sitearch", correct, has to go into the arch specific dir. Be that /usr/lib in i386 or /usr/lib64 on x86_64. Please, tell me where I'm failing English here, as it is my native language and I'd really like to know.
Add the OP's quote that is missing above and you'll see what you were meaning with "part of a python's module". I replied to the original post of yours, where all the context is present and I think it's quite clear.
E.g. your answer only makes sense if the packager was implying to tear foo.py apart into an arch-dependent and arch-independent part, which is certainly not what he wanted to do.
On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote:
On Sat, Sep 02, 2006 at 11:09:22AM -0400, Jesse Keating wrote:
On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote:
Due to the way that python works, if any part of a python's module is arch specific (sitearch), the entire thing has to go into sitearch. Python will not import part from sitearch and part from sitelib. So it'd all have to go in sitearch.
[snip]
If you have a module, importable module that is, has an __init.py__ and all that, if you shove part of it in sitearch and part of it in sitelib, it won't work. Is this statement wrong? If so, please do explain.
You mean just the way python-elementtree (and thus yum) works exactly that way since FC3?
Yes, that statement is wrong, just log onto a multilib system and check ownership of parts of sitelib. For example on FC5/x86_64:
# rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm\n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64
None of your examples violate what Jesse is saying, although they may need some explanation:
aqbanking-1.8.1beta-3.1.x86_64.rpm
- The python portion of this exists entirely in sitelib. There's no mixing of sitelib and sitearch.
audit-libs-python-1.1.5-1.x86_64.rpm
- There are two separate modules in this one. audit and _audit. They exist at the toplevel: %{sitelib}/audit.py and %{sitearch}/_audit.so. The _audit.so portion is referenced by the audit.py portion but it is not the same. If the modules were structured like this: %{sitelib}/audit/{__init__.py,audit.py} %{sitearch}/audit/{__init.py,_audit.so} then the modules would conflict and current python will find only one of them. [1]_
avahi-tools-0.6.10-1.FC5.x86_64.rpm
- Exists entirely in sitelib.
python-elementtree-1.2.6-4.2.1.x86_64.rpm
- Two separate modules: elementree in sitelib and cElementTree in sitearch. Same as audit-libs-python.
wireshark-0.99.2-fc5.2.x86_64.rpm
- Exists entirely in sitelib.
[1]_: Python-dev thread explaining this: http://mail.python.org/pipermail/python-dev/2006-March/062462.html
-Toshio
packaging@lists.fedoraproject.org