RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Greg Swift]

On Thu, Dec 6, 2012 at 2:05 PM, Kevin Fenzi <kevin at scrye.com> wrote:

> A few more questions:
>
> - Who is going to write/maintain this plugin? :)
>

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.


> - How do you plan on making sure everyone using EPEL is using the
>   plugin? Have a Requires in epel-release? That strikes me as pretty
>   ugly.
>

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.


> - Who is going to update all the compose/build tools/scripts to handle
>   this metadata.
>

goes back to the first question.


> - How is the metadata added? By maintainer? What if they don't update
>   it?
>

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.


> - What are the metadata keywords?
>
> * Breakable = excluding this update because it needs intervention
> * Insecure = this package is no longer updated and insecure
> ?
>
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"

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?


> - How do you handle trains of updates?
>
> foo-1.0-1 pushes out to stable
> <time passes>
> foo-2.0-1 pushes out, marked 'breakable' because you have to manually
> update configs.
> <time passes>
> foo-3.0-1 comes out, it's compatible with 2.0-1, no changes needed.
>
> Does someone still on 1.0-1 get upgraded to 3.0-1 since it's not
> incompatible marked?
>

The rule that I provided in my original example would apply here:

foo version 2+ is a breakable update for versions <2 or 1.*

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.

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:

zabbix* version 1.6+ is a breakable update for versions <1.6
zabbix* version 1.8+ is a breakable update for versions <1.8
zabbix* version 2.0+ is a breakable update for versions <2.0

Theoretically one could even do a partial update, say 1.4 -> 1.8 using 'yum
--reallyupdate update-to zabbix-1.8'

Also, would need a good name and cli switch too ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121207/90bcca67/attachment.htm>