Hello Robert,
Let me first introduce to you the IUS Community Project [1]. We started this
project a year and a half ago to serve this type of situation. For those that
are not familiar, we [IUS] maintain a repository of packages that explicitly
replace packages in RHEL. So where EPEL is an 'add-on' repository and has
strict policies about conflicting with RHEL... the IUS project has
'replacement' packages and also has strict policies:
• Can not Obsolete a Stock Distro Package
• Can not have the same name as another Stock Distro Package
• Must Provide the software it is replacing and be [more or less] compatible
with other Stock Distro Packages that require it.
• Must explicitly Conflict with a Stock Distro Package (via the spec). For
example the package php53 “Conflicts: php < 5.3″, but it “Provides: php =
%{version}”.
• Must not automatically install, upgrade, or replace Stock Distro Packages
when subscribing to the repo.
This is also how the 'replacement' packages in RHEL function. The php53
package in RHEL "Conflicts: php < 5.3", but "Provides: php =
%{version}-%{release}". Therefore, it resolves the dependency for other
packages that require 'php' such as phpMyAdmin, etc. That said is not
compatible with say, 'php-pecl-XXXXX'... as those packages are compiled against
php source.
Also note that IUS was brought up in the EPEL meeting nearly a year ago and at
the time was decided that if people were interested in such packages, to get
involved with and contribute to IUS... rather than doing so in EPEL.
The rest of my comments are in line.
On Apr 18, 2011, at 7:04 PM, Robert Scheck wrote:
> I know the "Philosophy of EPEL" says "to never replace or interfere with
> packages shipped by Enterprise Linux", but why should we have more strong
> rules than Red Hat has? Let us look to python in EPEL-5: We're shipping
> python26* packages - isn't this a "replace packages shipped by Enterprise
> Linux" somehow?
Actually no, the python26 packages are a parallel install (side-by-side). The
python26 package does *not* "Conflict: python < 2.6" nor does it "Provides:
python":
# rpm -q --provides python26 | grep python
config(python26) = 2.6.5-6.el5
python(abi) = 2.6
python-abi = 2.6
python26 = 2.6.5-6.el5
If it were to 'Provides: python = %{version}-%{release}' then it would
interfere with stock Python, and therefore conflict with RHEL. As it stands,
python26 does not conflict with RHEL and *does* meet EPEL guidelines. Now with
regards to your package, I would imagine that it more or less follows what RHEL
did with postgresql84 or php53.. and also what IUS does. In that case it does
*not* currently meet EPEL guidelines because it conflicts with RHEL. The
question is, does EPEL want to allow 'replacement' packages such as this? From
the experience of starting and running IUS, I can tell you that things can get
complicated very quickly. It could potentially add a lot of clutter to EPEL
and it would be my vote to keep EPEL as clean as possible... and keeping it a
'Add-on' repo and not a 'Anything goes' repo. Something that should be noted
is that RHEL has implemented these packages on a very very small scale (just a
handful). If everyone just starts adding packageXY replacement packages to the
repo... it can get real messy.
Additionally, it should be considered that this is the exact problem that IUS
is solving. IUS has a specific goal and a specific audience. Personally, I
really don't think RHEL should be introducing php53, and postgresql84, etc into
base RHEL... but that is their call. The question we need to ask is, does EPEL
want the headache of managing 'replacement' packages? You also have to
consider that this doesn't end at 'postfix26'... users always want the latest.
So soon enough you will need 'postfix27' and/or 'postfix3' which likely won't
happen because they are all separate packages so the postfix26 maintainer isn't
responsible for packaging newer versions. One of the goals of IUS is
maintaining multiple 'stable' branches for popular software. For example
mysql50, mysql51, mysql55 are all available in the ius-5 repository. The
acronym itself stands for 'Inline with Upstream Stable'... meaning we have
looser 'upgrade' policies because our primary goal is offering the latest
versions of a branch. Introducing 'postfix26' to EPEL is only good for so long
until branch 2.6 is considered old... or an upgrade is no longer backward
compatible... then what?
We [EPEL] do need to have some way to make a decision regarding EPEL's policy,
but I also ask that we consider what the IUS project has already done over the
last year and half. We get something like 15-20k unique users a month on the
mirrorlist service... and it has become a well known resource for upgrading
specific RHEL packages. It wouldn't make any sense to start duplicating
efforts with IUS.
>
> Coming back from theory to reality: If you install a postgresql84, do you
> really want to install an old postgresql 8.1 in parallel? No, you don't
> want to do this, because 8.4 is much better. Why would somebody want to run
> a very old postfix 2.3 in parallel with a postfix26? It makes same less
> sense to run two different PostgreSQL versions as it does for Postfix. If
> you decide to explicitly use the newer versions by switching manually, why
> do we need to take care for parallel installation? Even if you additionally
> install postfix26, you're on your own, because Red Hat won't support this
> new package, but only the original postfix one. What's the real benefit of
> parallel package installations in cases like this?
In my opinion, there is no point in doing a parallel install for packages like
this. From my experience I've found that users want something upgraded, but to
work the same as it did before. Meaning... if I upgrade 'php' to 'php53' I
want to still be able to call '/usr/bin/php' and not '/usr/bin/php-5.3'.
Python is an exception because the system is so heavily dependent on Python
that you can't upgrade it... you need to side-by-side install it.
With regards to PostgreSQL and other services... you have the issue of ports.
If postgresql84 installed parallel to postgresql, then what port would
postgresql84 listen on? It gets more complicated... where the majority of
users just want a newer postgres and don't care about backward compatibility.
That said, then going the 'replacement' package route... a lot of trouble comes
in when you consider everything in the distro that is compiled against the
package you are replacing. Providing a 'replacement' package means you need to
ensure that any programs compiled against the original still work. So anything
compiled against postgresql are most likely not going to work with just
postgresql84 installed because there are different client libraries. So now
you need postgresql-libs and postgresql84-libs installed to be backward
compatible. Thats all fine and dandy if those two packages don't conflict at
all.
This is all just using postgresql as an example.... but the point is, the
complexity of the repo and the potential for broken dependencies, or yum
resolution conflicts, or build system failures, etc... just multiplied by X
number of times. Does EPEL want that headache for potentially hundreds or
thousands of 'replacement' packages on top of what is already in the repo?
>
> I'm mentioning this, because some people dislike the idea to do the same in
> EPEL what Red Hat already did for RHEL. Shouldn't we think about what makes
> sense rather just trying to follow old rules from former times?
>
I think there is a specific audience for this type of upgrade... and I don't
think its ideal to introduce it into EPEL. Also, we [IUS] are in no way trying
to steal EPEL's thunder with IUS or compete in anyway. IUS actually relies on
EPEL to resolve dependencies... and it is our view that the two should be
completely separate. In the past we've had packages in IUS that we've ported
to EPEL or removed in favor of EPEL (python26, git17, etc)... and we are all
also Fedora/EPEL contributors. We just think the IUS packages are better off
in their own repo with their own goals and policies.
EPEL *adds* packages to RHEL... IUS *replaces* packages in RHEL. It keeps
things a lot cleaner. When you try to mix the two into a single repo you
increase complexity, as well as risk of unknown incompatibilities and issues.
Sorry for such a long response, but it's a lot of detail to cover.
References:
[1] http://iuscommunity.org - http://launchpad.net/ius -
http://wiki.iuscommunity.org
---
derks
_______________________________________________
epel-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/epel-devel-list
