This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1476431 - alternatives links lost when switching back from 3rd-party postfix to stock postfix packages via yum shell
alternatives links lost when switching back from 3rd-party postfix to stock p...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: postfix (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Jaroslav Škarvada
Depends On:
  Show dependency treegraph
Reported: 2017-07-28 21:37 EDT by Peter Ajamian
Modified: 2017-10-05 11:18 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Ajamian 2017-07-28 21:37:37 EDT
Description of problem:

If someone installs a 3rd-party postfix package (under a slightly different name) to replace the stock postfix, and later switches back to the stock postfix package the alternatives links get lost.

What happens is that if the package name is different yum sees it as a different package and not an upgrade / downgrade of the same package, so it does not set $1 in the %preun script.  Because %preun from the package being removed is run after %post in the package being installed, the alternatives links created in %post are removed by the %preun section of the old package.

Version-Release number of selected component (if applicable):
2.10.1-6 but applies to all versions and releases in RHEL 6 and 7.

How reproducible:

Steps to Reproduce:
1. Install a 3rd party postfix with a slightly different package name, such as the one available from ghettoforge here:

2. Use yum shell to replace the new postfix package(s) with the stock postfix:
# yum shell
> remove postfix3\*
> install postfix
> run
> quit

3. Check alternatives data for mta:
# alternatives --display mta

Actual results:
No alternatives data or links for postfix mta.

Expected results:
Alternatives links and data should be present for mta.

Additional info:
This is easily fixed by moving the alternatives --install from %post script to %posttrans.  In so doing the alternatives links will get created after the %preun script is run and so the %preun script from the 3rd-party package will not end up removing the links created by the stock postfix package on install.

This can be worked around by running yum reinstall postfix after the yum shell command.  Since yum will set $1 in this case the reinstall will not run the alternatives --remove in the %preun script and the links will remain.

This issue also exists in RHEL 6 and probably in all current Fedora versions.  Feel free to copy this bug report across to all applicable distributions.

Comment 2 Peter Ajamian 2017-09-22 23:50:16 EDT
Can I get a response for this, please?  Even just to show that it's been acknowledged other than leave it as status "NEW"?
Comment 3 Jaroslav Škarvada 2017-10-05 08:26:02 EDT
I think your use case is invalid and unsupported. You shouldn't mix such way 3rd party packages with distro's packages. If you have to do it you should either:
a) use 3rd party packages with the same name but different VR (version/release suffix), i.e. postfix-3.* in your case
b) use 3rd party package with different alternatives name/suffix (e.g. .postfix3 in your case)
c) manually remove distro's postfix by 'yum remove postfix' and then install your 3rd party postfix package by 'yum install postfix-custom'. It should also work the opposite way, i.e. with two transactions, not with single transaction.

But in either case it's unsupported and you are on your own.

a), b) needs changes in 3rd party repo. I think it's not worth to workaround it, it's against RPM logic [1]. I.e. at first new package version is installed then the remnants of old package is uninstalled. Cleanup is controlled by "$1". It's meant to work this way.

Comment 4 Peter Ajamian 2017-10-05 10:13:15 EDT
Before going into this I'll say that I certainly understand if this is not a supported scenario, but I filed the bug because it's a case where things break when you move from a 3rd-party package back to the stock package and this can lead customers to believe that the stock postfix package is broken.

Also I'll disclose at this point that I'm responsible for the postfix3 packages at GhettoForge.

Here's my thoughts on your three proposed solutions above:

a) 3rd party packages with the same name end up requiring workarounds such as yum priorities or using exclude and includepkgs.  Nonetheless GhettoForge did initially use postfix for the package name until the 3.0 release at which I decided to change the name so as not to force an incompatible upgrade when changing to dynamic map support.  At any rate, the postfix3 name is now here to stay and is not likely to be changed.  Also it is very likely that other 3rd party packagers will stick to the name postfix as most will likely simply rebuild the latest packages from Fedora.

b) It is far less likely that 3rd-party packagers will change the alternatives suffix than that they will change the package name.  In the case of GhettoForge I will look into it, but I must consider how it will affect breakage for existing users and I feel like there is a chance it likely will.  From an end-user perspective it is, imo, completely unreasonable to expect the end user to check the alternatives suffix before installing a package or even to have a remote understanding of how it will affect situations like this.

c) yum remove postfix will also remove all of postfix's dependencies, which in some cases could be quite a large number of packages that would then have to be installed again.  The entire reason for doing it in a single transaction with yum shell is to avoid this nightmare scenario.

I initially had this same issue with people switching from the stock postfix to postfix3 in GhettoForge.  After quite a lot of troubleshooting I figured out the issue and the solution I came up with was to move the alternatives stuff to %posttrans.  In all my testing and my user's testing from that point it has fully eliminated the problem on my side without any further issues.  I have documented the problem with switching back along with the suggested workaround mentioned earlier on the GhettoForge Postfix3 wiki page as a courtesy to my users and your customers who wish to switch back and I have filed this bug for the same reason.  To me this is the best I can do to fix the situation from my end of things.  As I said, though, I fully understand if this is an issue that you don't want to support for policy or other reasons, but do keep in mind that it is a problem that occurs not when switching to a 3rd-party package, but rather when switching *back* to the stock RHEL package, so it makes the RHEL package look bad from that standpoint.  That said the workaround is documented and it's a fairly minor issue.

At any rate, I've filed the bug report, I've provided the full details of the cause and what I believe to be a good solution for it.  The ball is now in your court, feel free to act on it or just close the bug if you still feel that this is not something you should address.


Comment 5 Jaroslav Škarvada 2017-10-05 10:53:14 EDT
Thanks for the explanation of the background. But ad-hoc exceptions aren't good. They could have unexpected consequences. The problem you described can occur with any 3rd package using alternatives. So let's say we could try to move 'alternatives --install' to %posttrans in Fedora Rawhide for all packages using alternatives (or more precisely I am not against such change), but it is not suitable for stable RHEL.

Could you try the b) approach? With the proper packaging (e.g. /opt or different prefix) users could have both packages installed and could switch between them on-the-fly by using 'alternatives'. Also if postfix is the only MTA installed it should work transparently for users, if not, they would need to just switch alternatives to postfix3 instead of the postfix.
Comment 6 Peter Ajamian 2017-10-05 11:18:24 EDT
I understand the stability issue and to an extent I agree with it.  While I don't think this is a change that could possibly cause any issues I'm certainly glad to hear that these sorts of changes, even seemingly innocuous ones aren't taken lightly for RHEL.

I'll consider b.  I might push a package out to my -testing repo and see how it goes.  As I said earlier, though, I have to consider what it will do to the stability of my current users' systems, so I'll think over it very carefully and try to do a lot of testing before I push such a change out to my stable repo.  Do consider, though, that it will only help users of the GhettoForge packages who wish to switch back, so it may not be worth it in the end.  It won't do anything for users of any other 3rd-party packages that have the same issue.  That said, I'm not aware of any other 3rd-party postfix packages for el that might possibly have this issue so it could be a non-issue there anyways.

Note You need to log in before you can comment on or make changes to this bug.