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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
