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

Re: Introduction of overlapping postfix26 package in EPEL-5?

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.


[1] http://iuscommunity.org - http://launchpad.net/ius - http://wiki.iuscommunity.org


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