Hello folks,
I would like to see a newer version of the "postfix" package in EPEL-5, because the Postfix 2.3 as shipped with RHEL 5 is pretty old. Postfix 2.3 is even known to cause trouble when setting up e-mail distribution lists via Active Directory in a specific combination.
In order to satisfy my needs, I've build a "postfix26" package. And please note, that it's not "postfix-2.6.x", but "postfix26". So it equals to what Red Hat did with "samba" vs "samba3x", "php" vs "php53" or "postgresql" vs. "postgresql84". My package is not upgrading a regular postfix installation.
But my package is overlapping with the regular postfix package from RHEL 5, e.g. both provide and use /etc/postfix or /var/spool/postfix - and provide /usr/sbin/postsuper or /usr/sbin/postconf. In the end that means that you can not install both packages at the same time, they are conflicting with each other.
Technically it should be possible to make the "postfix26" package somehow in parallel installable, but that requires a) patching postfix, b) lots and lots of testing and c) SELinux adaptions - a huge effort for less result.
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?
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?
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?
Unfortunately the IRC meeting today was not helpful nor does EPEL have some kind of a Steering Commitee that could vote on this somehow. How to get a decision for such things? Doing a voting on the mailing list? If there is no chance for postfix26 as it's packaged now in EPEL, I would like to see some kind of a real result not just pointing to our old rules that were in parts done by people who are maybe no longer contributing to EPEL at all...
Ideas? Comments? Recommendations? Suggestions? Votings?
Greetings, Robert
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
Hello BJ,
BJ Dierkes wdierkes@5dollarwhitebox.org a écrit:
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...
Thank you for bringing this up. As was not aware of IUS myself and I am glad to learn about it. I have one question though. Why can't IUS be a Fedora branch, like EPEL? Both would be separate, but would still leverage the (IMHO) wonderful Fedora infrastructure and mindshare.
Hello,
On Tue, 19 Apr 2011, BJ Dierkes wrote:
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:
I'm aware of IUS, but it's - sorry - yet another non-well known repository with software for RHEL out there. In a security audit, some has already to argue for EPEL, which usually works, because it's well known, but it starts to get much harder with RPM Fusion already. So I don't want to imagine the pain at an audit when IUS repository is used and in the end it's equivalent to our internal company repository, but considered trustful, because it is maintained in-house.
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?
The Postfix 2.6 branch is already old because RHEL 6 is shipping old stuff that is EOL at upstream. The only benefit of 2.6 in EPEL 5 is, that RHEL 6 is maintaining that version longer than RHEL 5 lifetime.
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.
From my point of view, the same reason applies for postfix. Why should it make sense to run "postconf26" rather "postconf" etc.?
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.
Dito, same for Postfix 2.6. Especially as SMTP forces you to port 25/TCP if you want to communicate with the rest of the world ;-)
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.
I'm aware about this, but all of that does not apply for Postfix here. Even PostgreSQL or PHP are more painful than Postfix in this case. And yes, such actions still need always to happen with using brain, because glibc210 or a kernel2632 on EPEL 4 is very likely to cause trouble.
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?
From my point of view, it only should be performed, where it makes sense, but not simply everywhere.
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.
Your argumentation still leaves the same risk to users if you enable EPEL and IUS at the same time, so I don't see any benefit of this argumentation.
Greetings, Robert
On Apr 25, 2011, at 8:00 AM, Robert Scheck wrote:
Hello,
On Tue, 19 Apr 2011, BJ Dierkes wrote:
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:
I'm aware of IUS, but it's - sorry - yet another non-well known repository with software for RHEL out there. In a security audit, some has already to argue for EPEL, which usually works, because it's well known, but it starts to get much harder with RPM Fusion already. So I don't want to imagine the pain at an audit when IUS repository is used and in the end it's equivalent to our internal company repository, but considered trustful, because it is maintained in-house.
Understandable with regard to audits for sure. IUS is still young, but I hardly feel EPEL is a better place for this type of package just because it would be easier for some to pass a security audit based on it being more well known. Additionally, just for clarity here, IUS has a lot of benefit over any other 'non-well known repo' in that its sponsored by Rackspace and isn't just a repo maintained by some random person on the weekend if/when they have time. Its a significant part of my teams $dayjob to ensure the success of the project (as well as contributing to Fedora/EPEL).
All that said, I understand where you coming from.
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.
Your argumentation still leaves the same risk to users if you enable EPEL and IUS at the same time, so I don't see any benefit of this argumentation.
Correct, but at that point the potentially negative affects above then only affect users of the separate repo (like IUS), and not all EPEL users (including those they have no knowledge of the additional packages). Meaning, you'd only incur the added risks/headache/issues/etc when subscribing to the additional repo and not just for subscribing to EPEL. If you look at it this way, the majority of EPEL users are looking for extra packages that they can't find in RHEL... where as all users of IUS (or similar repo) are looking for newer replacement packages that currently suck in RHEL. It is a pretty significant difference in audience needs. Extra packages vs. replacement packages.
On Apr 20, 2011, at 10:06 AM, Dodji Seketeli wrote:
Thank you for bringing this up. As was not aware of IUS myself and I am glad to learn about it. I have one question though. Why can't IUS be a Fedora branch, like EPEL? Both would be separate, but would still leverage the (IMHO) wonderful Fedora infrastructure and mindshare.
We did have that very discussion in #fedora-meeting over a year ago, and at the time it was decided that... EPEL itself has enough challenges in packaging and maintaining itself that adding another repo was just not in the cards. Ultimately we decided any packagers interested should participate in IUS and that merging IUS under Fedora Project wasn't feasible at the time.
We [IUS] are certainly open to talks regarding this topic of having an 'IUS' repo under Fedora (that sits next to EPEL)... which I think is a better conversation than allowing IUS type packages in EPEL. Perhaps a topic for next epel meeting. My only concern with that is... IUS has a pretty niche audience, and a very specific purpose in the grand scheme of things. Fedora/EPEL would really need to weight the pros and cons on whether it makes sense to go down that path or not.
--- derks
Thank you BJ for following up on this,
BJ Dierkes wdierkes@5dollarwhitebox.org a écrit:
On Apr 20, 2011, at 10:06 AM, Dodji Seketeli wrote:
Thank you for bringing this up. As was not aware of IUS myself and I am glad to learn about it. I have one question though. Why can't IUS be a Fedora branch, like EPEL? Both would be separate, but would still leverage the (IMHO) wonderful Fedora infrastructure and mindshare.
We did have that very discussion in #fedora-meeting over a year ago, and at the time it was decided that... EPEL itself has enough challenges in packaging and maintaining itself that adding another repo was just not in the cards. Ultimately we decided any packagers interested should participate in IUS and that merging IUS under Fedora Project wasn't feasible at the time.
OK. Good to know. At least the topic got discussed.
We [IUS] are certainly open to talks regarding this topic of having an 'IUS' repo under Fedora (that sits next to EPEL)... which I think is a better conversation than allowing IUS type packages in EPEL.
I think having an IUS repo under Fedora that sits next to EPEL is the right to do as well, barring of course the possible practical difficulties that it would imply.
Perhaps a topic for next epel meeting. My only concern with that is... IUS has a pretty niche audience, and a very specific purpose in the grand scheme of things. Fedora/EPEL would really need to weight the pros and cons on whether it makes sense to go down that path or not.
Indeed.
Thank you for sharing this insight.
On Tue, Apr 19, 2011 at 2:04 AM, Robert Scheck robert@fedoraproject.org wrote:
Technically it should be possible to make the "postfix26" package somehow in parallel installable, but that requires a) patching postfix, b) lots and lots of testing and c) SELinux adaptions - a huge effort for less result.
As you say it's technically possible and looking at other packages many people have gone to a lot of lengths to make packages co-exist. This is for me one of big benefit's of EPEL over some other repositories is that I know (hope) it won't break existing installations. Of course there's a place for genuine updates of packages and IUS is doing a good job providing that. I agree this is a major pain at time times, e.g I've been trying to get a parallel version of apr and apr-util built in a sensible way for some time now. I'd rather live with this packaging pain though.
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?
python26 co-exists perfectly well with default python.
epel-devel@lists.fedoraproject.org