<br><br><div><span class="gmail_quote">On 3/3/07, <b class="gmail_sendername">Axel Thimm</b> <<a href="mailto:Axel.Thimm@atrpms.net">Axel.Thimm@atrpms.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Oh, we have much worse that that already in place:<br><br>3:<br>- customer buys RHEL<br>- customer get package foo from EPEL that ships with a bar which<br> does not exist in RHEL, so everybody thinks it's fine<br>
- bar fubars customer's system (bar is a plugin, daemon, kernel<br> module, or something similar)<br>- customer report to RH that system does not work (doesn't boot,<br> firefox crashes, kernel oops)<br>- RH speds support time on customer only to find out that the bug is
<br> not directly in firefox/kernel/etc. but in a pure add-on package<br><br>In fact in all these years of "replacements" 3) has happened far more<br>often than 2) - the metrics would be 3)/#add-ons compared to
<br>2)/#replacment, but 2) is very close to zero.<br><br>So, if we are not in a worse position that we already are, why not<br>benefit and have Bill update/fix guille in the "epelplus" repo?<br></blockquote></div>
<br>This problem already exist for RH with third party packages / kernel modules / script installs. Third party stuff must account for a good 90% of the kernel dump cases we open with Red Hat. Their answer is simple, remove the third party stuff and reproduce the problem. Of course we can't but we do know who needs to do the fixing at this point.
<br><br>From a customer standpoint the only difference I see between this and a EPEL package is that (if my experience with FE holds true) I might actually get a fix with out needing to arrange twelve conference calls, and eventually refusing to pay another cent to the ISV. Y'all do a much better job than any ISV I've ever dealt with. Keep up the good work!
<br><br>Now the case where a package has upgraded some thing Red Hat provides is another ball of wax. Red Hat still has the right to refuse to support someone else's package, but now its not as easy to get rid of. Sure I can downgrade but I'm sure some developer of mine will have found the only feature not implemented in the version Red Hat ships with. I'm constantly finding boxes where they've upgraded python and have broken all of the system utils, and more importantly yum.
<br><br>The part that really worries me is the case where say Red Hat does decide to upgrade a package to a similar or higher version than the one provided by EPEL. Now I'm in some odd situation where either package may upgrade the other depending on how close they are to each other.
<br><br>At least if there is a plus, bleeding, danger, whatever repo, I can use either the protectbase, or priorities plugin to yum to provide some degree of security. The brave souls willing to negate their support (or those running CentOS, ect. where support isn't the issue) can test the watters and report back to the more timid. ;-)
<br><br>Russell<br>