On Sat, Feb 6, 2010 at 1:29 PM, Kevin Fenzi <[email protected]> wrote: > On Mon, 1 Feb 2010 13:51:17 -0700 > Stephen John Smoogen <[email protected]> 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 > [email protected] > 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
