Bug 238608
Summary: | python-kaa-metadata doesn't obsolete mmpython 0.4.10 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ville Skyttä <ville.skytta> |
Component: | python-kaa-metadata | Assignee: | Nicolas Chauvet (kwizart) <kwizart> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | axel.thimm |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-02 23:13:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 238907 | ||
Bug Blocks: |
Description
Ville Skyttä
2007-05-01 19:23:12 UTC
I will bump the versionning indeed... I think it provides such drop-in replacement: %{_bindir}/mminfo is bundled both from mmpython and kaa-metadata I wasn't using mmpython package but freevo uses kaa-metadata... I think packages that was using mmpython can now uses python-kaa-metadata! Do you encounter problems with such applications ? I don't myself use mmpython or kaa-metadata for anything, but a quick inspection tells me that it's not a drop-in replacement. Software written in Python that uses these extensions is affected; with mmpython you'd do something like "from mmpython import *" or "import mmpython", but that doesn't work with kaa-metadata - with it one needs to do "from kaa.metadata import *" or "import kaa.metadata" - and that doesn't work with mmpython. If that's correct, they're not compatible and I think the Provides: python-mmpython and Provides: mmpython should be removed. That's mean that if i drop Provides: mmpython < %{version}-%{release} Then when someone will install python-kaa-metadata it will also drop mmpython and package that need mmpython (as you describe) will fails... So maybe it would be better to check if any updates are avaiable for packages to link to kaa-metadata... But i would think packages are using the mminfo python script in _bindir, so nothing change from mmpython or kaa-metadata... Anyway, python-kaa-metadata and mmpython cannot be installed together so i would say that there is a need to check: - packages (mainly third part repo) that Requires mmpython - How they need mmpython ( * by using mminfo : -> good * by importing mmpython in script :- > Bad for kaa-metadata compat with mmpython) |---> They is a need to check if upstream can provides an updated version that use kaa-metadata first... (thinking on others solutions if needed...) repoquery --whatrequires --alldeps mmpython --repoid=atrpms didn't ouput anything - maybe there is some BR (i don't knwo how to check then...) others main third part repo didn't seem to Requires it also... I'm would like to rebuild it to obsolete mmpython 0.4.10 but it fails on libdvdread-devel for ppc64 (only for devel then) (In reply to comment #4) > repoquery --whatrequires --alldeps mmpython --repoid=atrpms > didn't ouput anything - maybe there is some BR (i don't knwo how to check > then...) > others main third part repo didn't seem to Requires it also... Well, is there *any* reason to have the Provides: mmpython and Provides: python-mmpython then, considering that they're kind of incorrect in the first place? They're still there in the specfiles in CVS. (In reply to comment #5) > I'm would like to rebuild it to obsolete mmpython 0.4.10 > but it fails on libdvdread-devel for ppc64 (only for devel then) http://www.redhat.com/archives/fedora-maintainers/2007-May/msg00074.html Obsoleting mmpython isn't needed anymore in rawhide (Fn +2) I plan to have them in EPEL4/5 soon ... |