Self-depracating packages was moin/mediawiki/etc [Need buildsys and rpm/yum eyes on this please]

[Stephen John Smoogen]

On Sat, Feb 6, 2010 at 1:29 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Mon, 1 Feb 2010 13:51:17 -0700
> Stephen John Smoogen <smooge at gmail.com> wrote:
>
>> Ok there are  a class of packages we are running into which I would
>> consider dead-end packages. The upstream usually makes changes between
>> major releases which make former releases non-functional without some
>> work (or in some cases LOTs of work). I think we should look at these
>> packages as not falling under standard packaging as it becomes a pain
>> in the ass to deal with on an enterprise packaging standpoint.
>>
>> Pulling up something I brought up a long time ago, I would like us to
>> figure out ways to deal with this.] As Bernard Johnson pointed out we
>> need to work on a naming convention for these applications to deal
>> with the fact that well, people rely on them, and their update policy
>> is a lot of the time crap.
>>
>> So taking Bernards and some stuff we talked about a year or two back..
>> lets see if we can do the following:
>
> ...snip...
>
> I have been pondering on this as well, and I wonder if another better
> approach might be:
>
> - Add another repo called "slipstream" or "bleeding" or
>  "incompatibeupdates" or some other catchy name.
>
> - Make new versions for the packages that fall into this issue in that
>  repo. ie, mediawiki, rdiff-backup, moin, nagios-3, etc.
>
> - For the case of packages where the old version works and still is
>  supported, let it stay in the normal epel/testing repo in addition.
>  For things that are not supported/broken/have known security issues,
>  remove them from the epel/testing repo.
>
> - Push updates to the bleeding repo as needed. The expectation for that
>  repo would be: We will try and avoid incompatible upgrades, but that
>  may be impossible, so you should watch every update from this repo
>  and test it in your env. Packages in the bleeding repo may well be
>  newer than ones in the stable repo. You should EITHER use the stable
>  repo only, or the bleeding+stable.
>
> I know another repo will be a big pain, but I think this would help us
> communicate to our users when something is a web app that is not really
> stable at all and updates rapidly and incompatibly. I think another
> repo (disabled by default) would communicate this better than 'nagios3'
> or 'mediawiki-foo' in the "stable" repo.
>
> Thoughts?

I think it has a nugget to work on so I am not against this..
What goes into stable? I can see slipstream getting all the packages
because its easier to break things.. but I don't see much reason to
put stuff into stable.


> kevin
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
>



-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning