[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]

>> 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.

I don't think the time frame is the only issue.  It can and probably
has happened in Fedora upgrades as well.  I can't think of a good
example off the top of my head, but I know I've had issues in the past
with some packages in the time frame of a supported Fedora version.
(it was probably mediawiki).  If Fedora doesn't want to have a policy,
or feels it doesn't need one, that's fine.  I was just hoping to get
it solved upsteam before we sat down and tried to invent our own

>> 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?

For this problem, unless we start spewing junk in /srv or something,
then no, I have no real answers for this one.  But rails specifically
expects applications to be containerized, and doesn't want
configurations in /etc and variable data in var etc.  I assume java is
much the same way with their jar/war/ear files, but I try not to touch
the stuff :) I think other web applications are normally like that

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