[Fedora-packaging] Is Conflicts acceptable in this case

[Ralf Corsepius]

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