[Packaging][deb] libarrow1600 shoud be libarrow1601 for 16.1.0

[kou]

Describe the bug, including details regarding any error messages, version, and platform.

XXX in libarrowXXX should match to XXX in libarrow.so.XXX.

Component(s)

Packaging

[raulcd]

This seems to happen only on minor releases 16.1.0 but not for patch releases. Is there a reason we update those on MINOR? Do we want to change the ABI? This is related to the discussion on conda here: conda-forge/arrow-cpp-feedstock#1409 (comment)

[h-vetinari]

@kou, in conda-forge/arrow-cpp-feedstock#1096 you asked to use a major-level pinning, indicating that the ABI (and thus the SOVERSION!) stays unchanged over the course of a given major.

In any case, the SOVERSION definitely shouldn't change for patch versions (unless you plan to allow ABI breaks there). The builds for 16.1.0 currently produce:

lib/libarrow.so
lib/libarrow.so.1601
lib/libarrow.so.1601.0.0

You can have both the major-level ABI-stability and the more granular detail if you do something like:

lib/libarrow.so
lib/libarrow.so.16
lib/libarrow.so.16.1.0

(ignoring for a second that you probably cannot go back from 1601 to 16; it could be 1700.<minor>.<patch> for arrow 17 though)

[jorisvandenbossche]

@kou do you mean for 16.1.0 instead of 16.0.1? (the title of the issue says 16.0.1)

[kou]

Oh, sorry. I was wrong. I've fixed the typo.

[kou]

@h-vetinari Sorry... I was wrong... We should have used a minor-level pinning.

[kou]

It seems that we have a logic for this:

arrow/dev/release/post-11-bump-versions.sh

Lines 70 to 105 in 1c9e393

	if [ ${BUMP_DEB_PACKAGE_NAMES} -gt 0 ] && \
	[ "${next_version}" != "${current_version}" ]; then
	echo "Updating .deb package names for ${next_version}"
	so_version() {
	local version=$1
	local major_version=$(echo $version | sed -E -e 's/^([0-9]+)\.[0-9]+\.[0-9]+$/\1/')
	local minor_version=$(echo $version | sed -E -e 's/^[0-9]+\.([0-9]+)\.[0-9]+$/\1/')
	expr ${major_version} \* 100 + ${minor_version}
	}
	deb_lib_suffix=$(so_version $version)
	next_deb_lib_suffix=$(so_version $next_version)
	if [ "${deb_lib_suffix}" != "${next_deb_lib_suffix}" ]; then
	cd $SOURCE_DIR/../tasks/linux-packages/apache-arrow
	for target in debian*/lib*${deb_lib_suffix}.install; do
	git mv \
	${target} \
	$(echo $target | sed -e "s/${deb_lib_suffix}/${next_deb_lib_suffix}/")
	done
	deb_lib_suffix_substitute_pattern="s/(lib(arrow|gandiva|parquet)[-a-z]*)${deb_lib_suffix}/\\1${next_deb_lib_suffix}/g"
	sed -i.bak -E -e "${deb_lib_suffix_substitute_pattern}" debian*/control*
	rm -f debian*/control*.bak
	git add debian*/control*
	cd -
	cd $SOURCE_DIR/../tasks/
	sed -i.bak -E -e "${deb_lib_suffix_substitute_pattern}" tasks.yml
	rm -f tasks.yml.bak
	git add tasks.yml
	cd -
	cd $SOURCE_DIR
	sed -i.bak -E -e "${deb_lib_suffix_substitute_pattern}" rat_exclude_files.txt
	rm -f rat_exclude_files.txt.bak
	git add rat_exclude_files.txt
	git commit -m "MINOR: [Release] Update .deb package names for $next_version"
	cd -
	fi
	fi

But it seems that we don't run post-11-bump-versions.sh for minor release.
@raulcd Could you tell us what post-*.sh are used (or what post-*.sh are not used) for minor release?

We may need to do this in 01-prepare.sh.

[raulcd]

I do run all post-*.sh scripts after a minor release but this is done after the release. We do set the final released version number on 01-prepare.sh so if we want to do any changes I do think it should be there. This is the commit that was created when setting the version for 16.1.0 on 01-prepare.sh:
7dd1d34

The post-11-bump-versions.sh sets the new snapshot versions and prepares main for the next major version number.

[kou]

Issue resolved by pull request 41859
#41859