[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