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
