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

[Toshio Kuratomi]

On Mon, Feb 01, 2010 at 05:25:53PM -0600, Michael Stahnke wrote:
> >
> > 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.
> >
> >
> Why try to solve this problem only in EPEL?  It exists in the main
> Fedora space as well.  Packages like Wordpress, Mediawiki, any Rails
> application, java stuff, etc are all like this.  I've often thought
> there's got to be a better way.  Should we get this in front of the
> package committee?   I see these with two major issues.
> 1.  Upgrading causes breakage or at least manual intervention

For this one, note that Fedora moves fast enough that it isn't the same kind
of issue as for EPEL.

ie: Fedora 11 packages moin-1.5
Fedora 12 packages moin-1.6

We do break compatibility on the release boundary and users do have to
perform manual upgrades there.  After 13 months, Fedora 11 is no longer
supported and we don't have to worry about security issues or bugfixes to
moin-1.5 anymore.  With EPEL, this is not the case -- you either have to
backport security fixes or perform an incompatible update within the RHEl-5
timeframe.

> 2.  Making these package FHS compliant is a real PITA and then often
> makes it so upstream can't/won't help due to your installation method
> (paths etc).
> 
This is a problem that won't be solved by ignoring the FHS.  Do you have
another idea of how to do it?

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