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
[NB: Not related to your issue, but
is almost always wrong.
Perl module packages should
> 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
> (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.
packaging mailing list