+1

-1

We cannot have a Change that is designed to break a DNF transaction. That is a fundamentally unsafe thing and would result in broken DNF and RPM state databases.

The change owner needs to come up with a solution that doesn't involve interrupting the upgrade process.

After a week, the vote is (+1,0,-1). Tagging for meeting.

The change owner needs to come up with a solution that doesn't involve interrupting the upgrade process.

I planned to test this before I'll commit, that's for sure.

What I had in mind - is to have two scenarios.

1. Usual user package update with "dnf update". In that case, "%pre" check is done, and if DB exists, we interrupt the update before its resolved (everything is backed up and FORCE_OPENLDAP_UPDATE is set, or the user moves the DB somewhere else and resolves the transition after the update)
2. If the user plans to update the Whole Fedora, then he is notified before the process starts so he can prepare his DB for the update.

But if it won't work because 'dnf' doesn't allow such things and Fedora policy forbids this, I have another option in mind.

Instead of breaking DNF, the update will be allowed as usual. BUT the server won't start after the update (because of the modified systems file). The instructions will be provided in the file.
The instructions will contain detailed information on how to do an offline backup and all of the necessary precautions.

This way, DNF interactions won't be touched. And the user's DB should be fine.

Still, I have other questions to discuss regarding the Change. So please, invite me for the meeting - spichugi@redhat.com

Topics:

• OpenLDAP 2.6 is released, and it has essential fixes (and I've tested it, it's the same ABI wise, so it's safe to update to that instead);
  New copr repo - https://copr.fedorainfracloud.org/coprs/spichugi/openldap-2.6/ ;
  New ABI report - https://spichugi.fedorapeople.org/ol_24_26_abi_check/compat_report.html .
• OpenLDAP upstream was using versions IN the shared library names (i.e. libldap-2.4.so.2.0.200). Now (in 2.6), it's finally just libldap.so.2.0.200. What I do - I provide libldap-2.4.so as a link to libldap.so because otherwise, I can't build other packages with the new openldap-2.6.0 (it complains that it can't find libldap-2.4.so)

So if it's okay, I'd like to receive guidance for these topics too.

Still, I have other questions to discuss regarding the Change. So please, invite me for the meeting

The meeting will be held 19:00 UTC, #fedora-meeting on irc.libera.chat.
(Actually those meetings are open to the public, anyone is free to join at any time, without a specific invitation.)

OpenLDAP 2.6 is released, and it has essential fixes (and I've tested it, it's the same ABI wise, so it's safe to update to that instead);

We generally want to go for the latest version in Fedora, so please just adjust the proposal to 2.6.

OpenLDAP upstream was using versions IN the shared library names (i.e. libldap-2.4.so.2.0.200). Now (in 2.6), it's finally just libldap.so.2.0.200. What I do - I provide libldap-2.4.so as a link to libldap.so because otherwise, I can't build other packages with the new openldap-2.6.0 (it complains that it can't find libldap-2.4.so)

It could be a problem if there were programs which are (possibly indirectly through other libraries) linked to both libraries. Such a situation could be created by first building a program that refers to both libs, and then symlinking one name to the other. IIUC, there's a risk that global variables (which have the same names in the global namespace) could be confused. But since you are only talking about building, then it should be safe to make the symlink. This is similar to how we symlink .so to some .so.x file which then is linked to .so.x.y.z.

This was discussed during today's FESCo meeting:
AGREED: Change is approved, with the proviso that the dnf upgrade must go through, and the service will refuse to start until the data is successfully migrated. Change owner will figure out the best way to communicate this to the admin (+6, 0, 0) (zbyszek, 19:23:28)