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