Some Python Packaging Questions

[Jeff Pitman]

On Monday 23 August 2004 21:56, Ville Skyttä wrote:
> On Mon, 2004-08-23 at 11:34, Jeff Pitman wrote:
> > 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...
>
> I'm not sure I understand the above.  But see below.

I've seen this floating around a few spec files:
%ifarch ia64
%define depsuffix ()(64bit)
%else
%define depsuffix %{nil}
%endif

Then, later:
libwhatever.so%{depsuffix}

But, maybe this is a very old way to do it and they now pile it on 
inside of /usr/lib64/.  I have no idea.  Someone needs to donate 64-bit 
systems to both of us!! ;)

> > > 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?
>
> Whatever the reasons, the decision has already been made.  

I would never aspire to change any decisions.  I am just trying to 
understand the policy a little bit better.

> AFAIK upstream Python distutils has differentiated between the two
> already for a long time, and it certainly does so nowadays.  

I would actually presume that the differentiation is rooted in autoconf 
and just carried over into distutils as a matter of reference.  The 
get_python_lib() code calculates what the prefix is by the following 
statement:

	prefix = plat_specific and EXEC_PREFIX or PREFIX

Running ./configure --help on any autoconf system, you see that:

Installation directories:
--prefix=PREFIX     install architecture-independent files in PREFIX
                          [/usr/local]
--exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

I have only been working the Unix scene for 7, 8 years and I've not seen 
much use of ./configure --exec-prefix.  Are we to presume that RPM 
proper should support this as a specific tag since autoconf has had 
this for a long time?  %{_exec_prefix} == %{_prefix}

> It seems to be 
> just a coincidence that the two point to the same location for 32-bit
> archs in Python packages distributed by Red Hat (and perhaps it's the
> default in upstream Python sources too, haven't checked, but
> nevertheless these locations are two different "entities").  There's
> no such coincidence with Python stuff from Red Hat for 64-bit archs
> AFAIK (this info is from reading the patches RH applies to the Python
> package for 64-bit archs, I don't have such a box either).

Why?  Is it because 64-bit can simultaneously run 32-bit libraries and 
64-bit libraries at the same time and they're concerned over name 
clashes?  Do they segregate 32-bit and 64-bit libs into different dirs?  
Maybe some programs can only have half their libs in 32-bit and the 
other half in 64-bit because of compilation issues.

It just seems all a waste of time, from a ignorant persons point of 
view.  You've really perked my interest ... now I have to get my paws 
on a 64-bit box.  I've got to see why anyone would care to make such 
seemingly anal retentive distinctions and 
why /usr/lib64/python2.3/site-packages 
or /usr/lib/python2.3/site-packages are somehow different entities.

I've not seen anyone use --exec-prefix, even in the Rawhide python.spec. 
So, not sure how get_python_lib() != get_python_lib(1) would ever occur 
in a standard distribution.

> >   sys.path would have to be modified anyway
> > and certainly the user really doesn't care.
>
> No, the user should not care and nobody has to modify anything to
> take this into account, things must Just Work.  The locations where
> distutils installs extensions by default need to be in the default
> load paths of that Python, otherwise I'd argue it's a bug in the
> Python package.

*Sigh*  I've still have not put a finger on this.  It seems people like 
to throw Python "apps" in /usr/share/app_name and libraries 
into /usr/lib/python2.3/site-packages.  I'm not 
sure /usr/share/app_name really makes any sense all the time.  Trick 
question: is epydoc an app or is it a library?

thanks,
-- 
-jeff