On Mon, 2004-08-23 at 11:34, Jeff Pitman wrote:
> 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.?
python-forward-compat provides python-abi = 2.2. It is _only_ useful
for < FC2 where the python package does not provide any python-abi, and
it "binds" itself to the installed python version, IIRC currently by
requiring /usr/bin/python2.2. The usefulness is that one can use the
same specfiles/SRPMS of python module packages regarding this bit for
many distro versions. AFAIK, depending on python-abi seems to be the
"official" way of requiring a certain version of Python, or a compatible
one (my guess: in the sense that a "compatible" one would have eg. the
site-packages dir of the version it is compatible with in its default
load path).
> So, out of my ignorance, %{_libdir} = /usr/lib64 on 64-bit platforms
Yes.
> 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.
> Anyway, the reason I think it's the same is because i386 == noarch under
> this scheme.
i386 == noarch? You mean that both i386 and noarch python packages
usually install into /usr/lib/python%{pyver}/... ? The point is that if
one builds the same noarch package on i386 or x86_64 or whatever using
the default configurations of the same distro version, the results
should be the same, including the install locations (otherwise it's not
a noarch package). This does not hold true for arch-dependent packages,
and this is nothing specific to Python extension packages.
> > 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. AFAIK
upstream Python distutils has differentiated between the two already for
a long time, and it certainly does so nowadays. 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).
> 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.
> 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.
I don't have that experience either, so someone else will have to fill
in here. Evil or not, if one does not do those mounts, I guess there's
not much to gain at all. But the reality is that the distinction is
there already, and spec templates and "best practices"-like packaging
instructions should take that into account.
> Help me out with why would this be a "beautiful day"?
"beautiful" did not come through as intended, it was a direct
translation from a Finnish saying. Think "One day you wake up and
notice that ...".
