Long-term package versions (RHEL 5+ extended to 10 years until EOL)

Xavier Bachelot xavier at bachelot.org
Tue Feb 7 23:22:59 UTC 2012


On 02/08/2012 12:09 AM, Ken Dreyer wrote:
> On Tue, Feb 7, 2012 at 3:57 PM, Bill McGonigle <bill at bfccomputing.com> wrote:
>> But that's just off the top of my head - others probably have better
>> ideas.
> 
> I appreciated Todd's approach with Puppet when that went from 0.25 to
> 2.6. Put it in updates-testing, and set the karma threshold really
> high (in that case, 10). It's clear to me as a sysadmin that 2.6 is
> coming down the line at some point, so I have an easy way to test when
> it's convenient to me, and I can provide feedback in Bodhi. Can we
> take that approach with other packages?
> 
Puppet 2.6 is a bit special, as upstream has been extra careful not to
break compatibility from 0.25 to 2.6. And speaking of puppet, the update
from 0.24 to 0.25 not so long ago was a way much bumpier ride, at least
at my shop.

Don't get me wrong, I'm not saying the pupet update wasn't handled
right, and I too like the long grace period in updates-testing, but that
is already a stretch in the EPEL policy, so it might need to be adjusted.

The parallel installable packages can be convenient and easy to do in
some cases, but that will definitely not be true in any case. I think
this approach was already used for mediawiki and looked doable for
bugzilla too. This is probably more in line with the current 'no
disruptive upgrade policy'. However, I'm not sure if the retirement
policy for such packages was discussed and/or documented.

Regards,
Xavier




More information about the epel-devel mailing list