[Bug 526126] Review Request: python3 - Python 3.x (backwards incompatible version)

bugzilla at redhat.com bugzilla at redhat.com
Mon Oct 19 19:19:57 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=526126





--- Comment #17 from Dave Malcolm <dmalcolm at redhat.com>  2009-10-19 15:19:53 EDT ---
Created an attachment (id=365267)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=365267)
Script to locate collisions between python 2 and python 3 rpms

The python 2 and python 3 packages must be parallel-installable.

In order to verify this, I've written a script to attempt to identify areas
where the two sets of packages could interfere with each other.

Specifically, the attached script takes the locally-installed set of python (2)
rpms as one PackageSet, and a locally-built set of python3 rpms as another
PackageSet, and attempts to locate
  - names listed in the "Provides" in one set of packages that also occur in
the "Provides" of a package in the other set
  - paths owned by packages in both sets

Is the script a reasonable test of the parallel-installability of the rpms?  Is
there anything else it should test for?

Running this script on my F11 machine's python rpms, together with a local
build of the candidate python3 rpms outputs some collisions:

==  Colliding "Provides" items: ==
Lots of "foo.so" lines appear (e.g. "_bisectmodule.so"), but probably
shouldn't.  The python modules have numerous auto-generated lines e.g.
"Provides: _bisectmodule.so".  I believe they're coming from the SONAME entries
in the built c extension modules, from the script "/usr/lib/rpm/find-provides".

Does anything actually use these provides lines?  My feeling is that they
should be suppressed for the Python 3 rpms, and probably for Python 2 rpms
also: the .so files aren't in the regular system search path for DSOs (instead,
being loaded by Python's module loading mechanism).

Looking at /usr/lib/rpm/macros, it looks like this can be overridden by setting
__find_provides to another script, or empty, though we probably shouldn't do
this; don't want to hide the python library itself.

== Colliding filesystem items: ==
I see the following collisions; duplicate ownership within the -debuginfo
packages.  I believe that these aren't a problem:
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/00
/usr/lib/debug/.build-id/0c
/usr/lib/debug/.build-id/2b
/usr/lib/debug/.build-id/39
/usr/lib/debug/.build-id/47
/usr/lib/debug/.build-id/61
/usr/lib/debug/.build-id/76
/usr/lib/debug/.build-id/7b
/usr/lib/debug/.build-id/94
/usr/lib/debug/.build-id/9b
/usr/lib/debug/.build-id/a1
/usr/lib/debug/.build-id/ba
/usr/lib/debug/.build-id/d3
/usr/lib/debug/.build-id/d4
/usr/lib/debug/.build-id/eb
/usr/lib/debug/.build-id/ed
/usr/lib/debug/.build-id/fd
/usr/lib/debug/usr
/usr/lib/debug/usr/bin
/usr/lib/debug/usr/lib

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the package-review mailing list