[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Mon, Feb 1, 2010 at 4:25 PM, Michael Stahnke <mastahnke gmail com> 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
> 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).

I believe it was brought up sometime ago in the murky passed packaging
and was listed as "Need someone to experiment with it first before we
make it for everyone." I could of course be completely pulling things
out of the ether on it... but that was why I had left it in limbo 2
years ago.. I didn't have the time/etc to do it locally. I have better
aim on time for this now.

If we can show it can be done, and how its done, its easier to get it
standardized knowing of course that our implementation will have to be
altered as corner cases come up.

> I'd rather see this handled by the   Package people and if we need
> specific discussion for EPEL, we can have it.
> Thoughts?
> stahnma
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list redhat com
> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]