Re: [Fedora-packaging] Is Conflicts acceptable in this case
Preliminary remark: I have absolutely no clues about ocsinventory.
On 10/09/2010 12:39 PM, Remi Collet wrote:
I'm thinking of adding (for ocsinventory package) a :
Conflicts: perl-XML-SAX< 0.96
No, this would be multiply broken.
Esp.you'd render all other packages which require perl-XML-SAX
uninstallable.
[NB: Not related to your issue, but
Requires/Provides: perl-<name>
is almost always wrong.
Perl module packages should
Require/Provide: perl(<module>)]
I cannot requires perl-XML-SAX>= 0.96, because
- this package doesn't requires perl-XML-SAX
I don't understand. Here you
say it "doesn't require".
- EL-5 have only perl-XML-SAX 0.14
When ocsinventory is installed (so, on EL-5 only) with
perl-XML-SAX-0.14, httpd eat all CPU :(
... and here you say "it eats all
CPU".
Is perl-XML-SAX an optional dependency of ocsinventory?
This seems related to
https://rt.cpan.org/Public/Bug/Display.html?id=29316
(patch is included in recent version)
If perl-XML-SAX were in EPEL, I could post a bug (RFE for update), but
it's a core RHEL-5 package...
IMO, the only clean solution is to "fix what is broken", i.e. to let RH
upgrade their package.
Therefore, my recommendation: File a bug/RFE against perl-XML-SAX for
RHEL, including the link you provided above and hope somebody @RH will
acknowledge that their perl-XML-SAX is broken and needs an upgrade.
Alternatives to work around your issue could be
* Hack oscinventory to use a private copy of perl-XML-SAX. I don't know
if this is easily doable; In most cases this requires hacking the
original package's search paths and careful filtering of rpm provides.
If you exactly know which file is broken, you could also try to only
provide a private copy of this broken file (with fix applied, of course)
* Hack ocsinventory to not use perl-XML-SAX. As this may introduce
functional regressions, this might not be feasible.
Ralf