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

[BJ Dierkes]

On Feb 1, 2010, at 5:25 PM, Michael Stahnke wrote:
> 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'd rather see this handled by the   Package people and if we need
> specific discussion for EPEL, we can have it.

I agree, I don't think this is just an EPEL thing, however the restrictions on non-compatible upgrades are much more stringent with EPEL than Fedora.  Of course in this case we are talking more specifically about packages that have no upgrade path, or a difficult one.. rather than just a non-compatible upgrade.

I think this discussion also overlaps with others that have occurred regarding simply the ability to introduce newer versions of software that people want, which is more appropriately from the 'new install' perspective rather than the 'upgrade' perspective.  That said, Fedora is introducing 'python3' parallel install in F13 which breaks the barrier for multiple packages of differing versions.  With Moin as an example, even if moin-1.5 was still maintainable... there is no way that I would use it for a new install via EPEL, forcing me to rebuild from Fedora packages and maintain my own set.  Where as if we were able to introduce moin18, or I guess moin19 now.. new installs would be peachy, and old users of moin-1.5 would not be affected.

This is pretty much exactly on the path of what The IUS Community Project [1] does with packages, but in a different context where IUS packages replace stock RHEL packages.  From a packaging standpoint, there isn't much difference.  The process [2] is rather simple, and after nearly 6 months since IUS launched there have been limited obstacles [3].  The basics are doing something like this (with moin19 for an example):

# before the preamble
%define basever 1.9
%define real_name moin
%define name moin19

# after preamble
Provides:  %{real_name} = %{version}-%{release}
Conflicts: %{real_name} < %{basever}

# and for all sub packages
Provides:  %{real_name}-subpackage = %{version}-%{release}
Conflicts: %{real_name}-subpackage < %{basever}


This is the IUS model, where replacement packages conflict and replace the existing package (not side-by-side except for Python).  If you are looking to enable side-by-side parallel installs of the original package, and the replacement (i.e. moin19) you are talking about a lot of extra work, which in my opinion isn't usually worth it considering most people [I would imagine] wouldn't want/need/care about running both side-by-side.

References:

[1] http://iuscommunity.org
[2] http://wiki.iuscommunity.org/Doc/DeveloperGuide#Converting_Existing_Packages_For_IUS
[3] https://bugzilla.redhat.com/show_bug.cgi?id=529719

---
derks