This bug was originally reported against the openldap-epel package in EPEL 9. The openldap-epel package is based on the openldap package (providing the subpackages not shipped in RHEL), and the rpm scriptlets for the openldap-servers package are the same. The issue described in the original bug report affecting an updates from 2.6.2-1.el9 to 2.6.2-2.el9 also affects Fedora, e.g. the recent update from 2.6.2-3.fc36 to 2.6.3-1.fc36 where the UPGRADE_INSTRUCTIONS file is left in place even though the update is from one 2.6 version to an other. This causes slapd not to restart after upgrade. Is this the intended behaviour also when updating from 2.6.x to 2.6.x+1, or from 2.6.x-n to 2.6.x-n+1? +++ This bug was initially created as a clone of Bug #2131659 +++ Description of problem: Recent versions of the openldap-servers package (2.6+) fail to start if UPGRADE_INSTRUCTIONS exists. This is to indicate to the admin that changes need to be made between version 2.4 and 2.6. But the file is also kept when an upgrade is performed from 2.6.2-1 to 2.6.2-2, which is the same (major) version. This isn't necessary and causes unnecessary downtime due to updates. Looking at the postinst scripts, it seems the UPGRADE_INSTRUCTIONS file is only removed on new installs, but never on upgrades. I believe it should also be removed if the major version of the old and new package matches. Version-Release number of selected component (if applicable): openldap-servers-2.6.2-2.el9.x86_64 How reproducible: Always Steps to Reproduce: 1. Install openldap-servers-2.6.2-1.el9.x86_64 2. Update to openldap-servers-2.6.2-2.el9.x86_64 3. Actual results: slapd is no longer running because UPGRADE_INSTRUCTIONS exists Expected results: slapd running after upgrade Additional info:
*** Bug 2134231 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening and setting release to rawhide as the behavior is unchanged there. A minor openldap update from 2.6.4 to 2.6.6 in a stable rawhide version (F38) just caused significant breakage for me here, and I think even a minor package upgrade with no change to the actual openldap version would also break. This means that anyone who actually makes use of the package has to disable any form of automatic updates, and that doesn't seem like a great idea. It seems to me that if the choice is between a package that might not restart properly because some openldap change requires some manual upgrade action, and a package that will _never_ restart because the package just works that way, I'll take the former. But really, that shouldn't happen anyway because in a stable release, the package maintainers shouldn't push changes which would require manual intervention anyway. In any case, please please please consider doing... something else. I will probably end up making a cron job/timer unit that deletes the file and tries to start slapd just so that if an update does break something, it will only stay broken if slapd really won't start automatically.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.