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@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review