<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 2:05 PM, Kevin Fenzi <span dir="ltr"><<a href="mailto:kevin@scrye.com" target="_blank">kevin@scrye.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A few more questions:<br>
<br>
- Who is going to write/maintain this plugin? :)<br></blockquote><div><br>good question. From my understanding that's a question for whatever path is taken. If i'm not mistaken the multiple repository path also required dev work. I'm looking to see if I can generate some free cycles to participate, so its not just me spouting an idea, but thats the most I can offer at this moment aside from these e-mails that are taking me ~24h to write ;) At the very least trying to cover some of the bases in this concept leaves an option and a basic blueprint for an interested party.<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- How do you plan on making sure everyone using EPEL is using the<br>
plugin? Have a Requires in epel-release? That strikes me as pretty<br>
ugly.<br></blockquote><div><br>yes, it is pretty ugly, but prettier than having people get packages that break their system. The situation I'm more concerned with is the new epel-release going out with the new yum-plugin-whatever. People not updating yet. A month or so later package blah is updated with a breakable update, and they get all 3 at the same time. oops. That's currently the main thing I don't have a suggestion for handling. Suggestions welcome.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Who is going to update all the compose/build tools/scripts to handle<br>
this metadata.<br></blockquote><div><br>goes back to the first question.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- How is the metadata added? By maintainer? What if they don't update<br>
it?<br></blockquote><div><br>Who generates errata now? I'd lean on the maintainer updating it as they should be the most familiar with it. What happens if a maintainer updates the repository right now with an incompatible update? In theory an update wouldn't get good karma if suddenly it just applied and was broken, or bugs would get created and people would gripe about it. All of which I believe happens already if there is an issue with an update process.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- What are the metadata keywords?<br>
<br>
* Breakable = excluding this update because it needs intervention<br>
* Insecure = this package is no longer updated and insecure<br>
?<br></blockquote><div>thats a good start. I'd probably come up with something like 'deprecated' instead of insecure, or maybe have both. This way you could mark unsupported by upsteam packages that may not be "insecure"<br>
<br>obviously we need to flesh out the specific scenarios this process is trying to address and come up with a succinct list of keywords and the associated errata format. Does anyone have any input as to these keywords?<br>
<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- How do you handle trains of updates?<br>
<br>
foo-1.0-1 pushes out to stable<br>
<time passes><br>
foo-2.0-1 pushes out, marked 'breakable' because you have to manually<br>
update configs.<br>
<time passes><br>
foo-3.0-1 comes out, it's compatible with 2.0-1, no changes needed.<br>
<br>
Does someone still on 1.0-1 get upgraded to 3.0-1 since it's not<br>
incompatible marked?<br>
<span></span></blockquote><div> <br>The rule that I provided in my original example would apply here:<br><br>foo version 2+ is a breakable update for versions <2 or 1.* <br><br>The goal would be to have a minimal number of rules per package to reduce overhead, and be able to support up to 13y of updates. To handle newer releases I think that all relevant rules should be applied over the life of the repository.<br>
<br>A prime example would be Zabbix, which in the life cycle of RHEL 5 has gone from 1.4 -> 1.6 -> 1.8 -> 2.0, all of which were breakable upgrades. Here would be the rules in the update:<br><br>zabbix* version 1.6+ is a breakable update for versions <1.6<br>
zabbix* version 1.8+ is a breakable update for versions <1.8<br>zabbix* version 2.0+ is a breakable update for versions <2.0<br><br>Theoretically one could even do a partial update, say 1.4 -> 1.8 using 'yum --reallyupdate update-to zabbix-1.8' <br>
<br>Also, would need a good name and cli switch too ;)<br></div></div></div>