Some Python Packaging Questions

[Jeff Pitman]

On Monday 23 August 2004 15:19, Ville Skyttä wrote:
> On Mon, 2004-08-23 at 09:27, Jeff Pitman wrote:
> > Some packages are using this as a Requires:, but not all. 
> > Fedora.us implements a slightly different scheme in the spec
> > template.
>
> FYI: the spec template used distutils.sysconfig.get_python_version()
> which is available only in Python >= 2.3; that has been changed to
> the sys.version[:3] approach in the latest version which should be
> published soon (bugzilla.fedora.us 1401).  (The fedora.us
> python-forward-compat package provides python-abi stuff for < FC2.)

Fair enough.  Can you elaborate on the python-forward-compat package a 
little bit more?  And why would it be useful for < FC2 where python 2.2 
never used python-abi = 2.2, etc.?

> > On my systems, this will always expand to the same versioned
> > library directory. Does this have to do with 64-bit somehow?
>
> Yes.  sitelib should always point to the architecture independent
> location (/usr/lib/... in current python packages), and sitearch to
> the arch-dependent one (%{_libdir}/... in current python packages). 
> With x86_64, there was a bug in the python package that resulted both
> of the above being %{_libdir} which again caused borkage (in a way
> that those macros expanded to wrong locations even if the sofware was
> installed to the correct ones) when a noarch Python extension package
> was built on x86_64.  That has been fixed in Rawhide.

So, out of my ignorance, %{_libdir} = /usr/lib64 on 64-bit platforms AND 
we have to worry about .so(64bit) for lib suffixes.  I guess I should 
get a 64-bit system to check this out, but from a surface-level it 
seems to be an awful hack.  I guess the suffixes are needed for pkgs 
that require /usr/lib/ or something...

Anyway, the reason I think it's the same is because i386 == noarch under 
this scheme.

> As of now, one could fairly safely use /usr/lib*/python%{pyver}/...
> everywhere, but I guess one beautiful day arch-independent Python
> extensions will be installed in /usr/share/python%{pyver}/...  And as
> noted above, one can redefine %__python to build for a custom Python
> installation in which case we can't assume much at all.

Why would this be even useful?  Segregation of compiled extensions (.so) 
and pure-python (.py) files?  sys.path would have to be modified anyway 
and certainly the user really doesn't care.  Zero gains, really, at a 
high-level view.  But, what do we gain really at a low-level view?  I 
don't do nefarious /usr NFS mounts and segregate based on architectures 
in a disparate environment, so I don't know what the advantages are.  
Help me out with why would this be a "beautiful day"?

take care,
-- 
-jeff