<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>That's the thing though. Upgrading the package to a version that obsoletes options you were using on the older version isn't 'broken', it's different. I know you don't feel that way about it. But what's the alternative? Red Hat forks the newer version of rngd, hacks on it to add back in the options that were taken out by the actual package authors, then has to mangle updates into this forked, hacked together code base from the upstream?</div><div><br></div><div>You think you had problems when they just updated the package to match the upstream? I don't want to see what happens if Red Hat addressed it in the alternate method I outlined.</div><div><br></div><div>-Scott</div><div><br>On Aug 31, 2015, at 3:41 PM, leam hall <<a href="mailto:leamhall@gmail.com">leamhall@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I can see breaking stuff if there's a big (Heartbleed) reason. But rngd in the last patch update, and last year it was one of the filesystem encryption methods. Can't remember if it was LUKS or ecryptfs. Either way, if you break stuff, aren't you supposed to be motivated to fix it? <br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 3:22 PM, Scott McBrien <span dir="ltr"><<a href="mailto:smcbrien@gmail.com" target="_blank">smcbrien@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>Red Hat doesn't guarantee to not break all the things, but rather things like ABIs and APIs. <a href="https://access.redhat.com/site/articles/rhel-abi-compatibility" target="_blank">https://access.redhat.com/site/articles/rhel-abi-compatibility</a></div><div><br></div><div>With the lifespan of a RHEL release growing from 5 to 7 to 10 years (plus extra years for those willing to pay for it), it's just not feasible to expect that the OS will stay as static as one might like. There are times where a package just needs to get refreshed to a newer version, where back porting may no longer be an option. Red Hat doesn't do this all the time, and there are some packages (like gcc or the kernel) where updating the package would violate the api/abi compatibility. Other packages are fair game though.</div><div><br></div><div>Taking my Red Hat off. I understand your frustration. This happened to me on RHEL 7 between 7.0 and 7.1 for one of the packages I use, and it was more severe than a couple of option changes. When talking with Red Hat engineering about it, it was obvious that they had no idea why I was miffed. I should clarify, the engineers had no idea why I would be miffed. The Product Managers understood, but figured out that there weren't a lot of people using the package so that upgrading it would add features and make it easier to use, and that it was worth the risk of putting off a couple of atypical customers (internal) to improve the product.</div><div><br></div><div>It happens, it's painful sometimes, but the decisions aren't made by random, there usually is a reason that it was decided to change the package. Whether you agree with that reason or not is a completely other thing ;-)</div><div><br></div><div>-Scott</div><div><div class="h5"><div><br>On Aug 31, 2015, at 2:58 PM, leam hall <<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div>If you're using rngd on RHEL 6, check to see if you're using the -i or -t options. RH did a major version upgrade, from 2.x to 5.x, and dropped support for those options. Unfortunately, if you do have them in your /etc/sysconfig/rngd file it will preclude rngd from starting at all. I've sent RH a kludgy work-around. Or you could use {Puppet|Chef|Salt|Ansible}, etc. Lots of possibilities. <br></div><br></div>I'm mostly frustrated because one of the RH standards is that they don't break stuff in the middle of an OS. This is the second time I've seen it in as many years, and the "we don't see that as a priority issue" tap dance is starting to bug me. <br><br></div>Leam<br><br clear="all"><div><div><div><div><div><br>-- <br><div><div><a href="http://leamhall.blogspot.com/" target="_blank">Mind on a Mission</a></div></div>
</div></div></div></div></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Ale mailing list</span><br><span><a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a></span><br><span><a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a></span><br><span>See JOBS, ANNOUNCE and SCHOOLS lists at</span><br><span><a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a></span><br></div></blockquote></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div><a href="http://leamhall.blogspot.com/" target="_blank">Mind on a Mission</a></div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Ale mailing list</span><br><span><a href="mailto:Ale@ale.org">Ale@ale.org</a></span><br><span><a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a></span><br><span>See JOBS, ANNOUNCE and SCHOOLS lists at</span><br><span><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a></span><br></div></blockquote></body></html>