Bump SONAME of libzfs and libzpool before 2.3.0 release

[Harry-Chen]

Motivation and Context

The ABI of libzfs and libzpool have breaking changes since last SONAME bump in commit fe6babc:

• libzfs: zpool_print_unsup_feat removed (used by zpool cmd).
• libzpool: multiple ddt_* symbols removed (used by zdb cmd), and many more.

Bump them to avoid ABI breakage.

See: #11817

cc @behlendorf

Description

See my commits. And here's the dpkg-gensymbols output comparing symbols from 2.3.0-rc1 to 2.2.6, for reference:

zfs-symbols.patch

How Has This Been Tested?

Compiled on my machine. Wait for CI run.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[satmandu]

Do any of the ABI changes affect programs shipped outside of OpenZFS (i.e., are any external consumers affected?)?

I assume that zpool and zdb are always packaged with OpenZFS, so they will always be packaged with a corresponding libzfs and libzpool and thus never break?

[Harry-Chen]

Do any of the ABI changes affect programs shipped outside of OpenZFS (i.e., are any external consumers affected?)?

Yes. For example, truenas's https://github.com/truenas/py-libzfs links to libzfs. There might be other tools leveraging these libraries.

I assume that zpool and zdb are always packaged with OpenZFS, so they will always be packaged with a corresponding libzfs and libzpool and thus never break?

Executables and libraries are separately packaged in both RPM / DEB, so they are theoretically not always bundled together. Although executable packages can specify dependencies on specific library versions (and this is what we are doing now both in upstream and distros), it is always safer (and required by most distro policies) to have a SONAME bump whenever ABI have breaking changes.

[behlendorf]

Thanks, yes a SONAME version bump is definitely in order.