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

[Kevin Fenzi]

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?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100206/5de13550/attachment.sig>