Bug 1476431

Can I get a response for this, please?  Even just to show that it's been acknowledged other than leave it as status "NEW"?

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.

[1] https://fedoraproject.org/wiki/Packaging:Scriptlets#Ordering

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.


Cheers,


Peter

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.

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.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.