OK, here is the original quoting. A user has both arch specific and
non-arch specific parts of a package and needs to decide which parts
to place under sitelib and which under sitearch.
Jesse's (wrong) answer is that if one needs to get into sitearch it
pulls the rest into there, too. It's not about files with the same
name under sitearch and sitelib as Jesse later explained, it's about a
package like python-elementtree and friends that has some parts that
are arch specific and some parts that are not. And there is no need to
move everything to sitearch contrary to Jesse's statement.
Everything clear as mud? Removing too much in quoting generates this
kind of confusion.
On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote:
On Sat, 2006-09-02 at 16:40 +0200, Sander Hoentjen wrote:
> On Sat, 2006-09-02 at 16:34 +0200, Sander Hoentjen wrote:
> > I am working on packaging cohoba, this is a python gui client/mission
> > control for telepathy. It has one small .c file, so I have a few
> > questions:
> > - because of the .c file the package has to by arch-specific i guess. Is
> > there a strong preference to package as noarch? (the c part is used for
> > changing the name for killall, so to put it as noarch i can just leave
> > that part out (not being able to killall cohoba), or add a dependency on
> > python-ctypes and add a small patch to cohoba to use ctypes to do it
> > instead)
If it can use all pure python, that would be best for the upstream
project. Why reinvent the wheel?
> i didn't want to send yet, so i'll continue:
> - should i just not care about arch vs noarch and package as arch
> specific, then where must i place the modules, all in python_sitelib and
> only osutils (the c one) in python_sitearch?
> thanks for any pointers
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.
Axel.Thimm at ATrpms.net