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
