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
_______________________________________________
epel-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/epel-devel-list
