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

[Stephen John Smoogen]

On 9 February 2012 13:29, Tom Diehl <tdiehl at rogueind.com> wrote:
> On Thu, 9 Feb 2012, Stephen John Smoogen wrote:
>
>> On 9 February 2012 09:47, Kevin Fenzi <kevin at scrye.com> wrote:
>>>
>>> On Thu, 09 Feb 2012 09:42:06 +0100
>>> Xavier Bachelot <xavier at bachelot.org> wrote:
>>>
>>
>>> Well, we could ship a package that removes them, or updates to the
>>> epel-release that conflicts, but I would not really like that
>>> personally. That forces things to be removed when it's not really
>>> giving people the choice of running the old thing still. (Perhaps
>>> internally where security doesn't matter so much to them).
>>>
>>
>> How about the following:
>>
>> XXX-replaceble (requires the latest package and installs that)
>> XXXversionnumber (the one that is packaged up.)
>>
>> When a package is going to be abandoned (like I did with mediawiki114)
>> one should put a last package with the same contents as the last one
>> and a doc file (and change to %description) saying "This package is
>> dead and abandonned. It is no longer supported by upstream and/or
>> EPEL. You are free to use this package as long as you like, but you
>> are the sole responsible party." Or some such thing.
>>
>> If you install XXX-replaceable it upgrades to the latest version as
>> needed. If you pull in the XXXversionnumber then you stay on that.
>
>
> So are you saying that mediawiki-1.14.0-45.el5 is orphaned? If so I
> totally missed that, so I guess that makes me one of the targets to
> this discussion. As such I like the above idea or something similar.

The mediawiki-1.14.0 and mediawiki114-1.14.x are both orphaned and
have been for a while. I believe I posted about that a while ago. The
reason for the orphaning is a) upstream has no interest in any version
outside of their 6 month lifetimes and b) the code base changes enough
that trying to backport security fixes are more likely to introduce
new ones.

the current mediawiki packages in EPEL are going to be orphaned soon
for similar reasons. 1.18 has such a large rewrite that trying to
apply Alex THimm's original patches to make it multi-homed won't work
and trying to get it to do other items is also likely to fail. So once
I get 1.18 reviewed and entered it will take over for 1.15 and 1.16
since they are not supported by anyone.

> Fortunately, in this case it is not a big deal because the wiki is not
> exposed to the net. It is strictly for my internal use but it would be
> nice to have known I should be doing something different. I guess I need
> to pay closer attention to this list and the announce list. :-)
>
> Currently, how can I tell if there are any other epel packages that have
> been
> orphaned?

Hmm I think quite a few. I can see if we can find a way to generate
that information.

> Regards,
>
> --
> Tom Diehl       tdiehl at rogueind.com      Spamtrap address
> mtd123 at rogueind.com
>
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd