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

Manuel Wolfshant wolfy at nobugconsulting.ro
Sun Feb 7 00:20:24 UTC 2010


On 02/06/2010 10:29 PM, Kevin Fenzi 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. 
>   
100% agree with you. But I am very much afraid that we do not have the 
resources.




More information about the epel-devel mailing list