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

Stephen John Smoogen smooge at gmail.com
Mon Feb 1 20:51:17 UTC 2010


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:

1) Declare a package will need to follow 'Bad-EOL' policy (whatever
that is finally decided)
2) Change the naming of the current package from <package>-x.y.z to
<package>xy-x.y.z with appropriate tags (obsolete? replaces with
predjudice?) to replace the package.
3) If EOL of old package add a standard file in the package outlining
that EPEL is EOL this package and will not do updates without
community help to do so. Also outlining that upgrading to newer
versions of the package is not simple and you should follow steps at
"Fill in page here if it exists."
3) Make packages in newer versions also match this name:
<package>(x+1).y.z-(x+1).y.z and keep that up to date until its no
longer possible.
4) Goto #2 when needed.


-- 
Stephen J Smoogen.

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




More information about the epel-devel-list mailing list