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

Tom Diehl tdiehl at rogueind.com
Thu Feb 9 20:29:40 UTC 2012


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.

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?

Regards,

-- 
Tom Diehl       tdiehl at rogueind.com      Spamtrap address mtd123 at rogueind.com




More information about the epel-devel-list mailing list