Control: affects -1 aapt android-libaapt
Control: reopen -1
Hello Roger,
thanks for your e-mail. Please see my response below.
On Sat, 21 Jan 2023, Roger Shimizu wrote:
Version: 29.0.6-21
This issue was resolved by commit:
-
https://salsa.debian.org/android-tools-team/android-platform-tools/-/commit/9cc4e88
I'm curious why you reported this issue on Nov. 2022 regarding a
version fixed on Aug. 2022.
And reported version didn't on oldstable, or oldstable-backports, either.
First of all, I am sorry for the confusion. I have Debian 11 on my system
and upgraded these packages to the version from bullseye-backports where
it happened to be version 29.0.6-20~bpo11+1 at that time. I did not use
this version number in the bug report because I thought it would be good
to use the version number when this issue occurred at first.
Anyway, now there should be no problem on the versions for the libraries.
I am sorry to tell you that your approach only fixes it for the binary
packages that are in control of src:android-platform-tools but that does
not include any other binary packages, e.g. aapt or android-libaapt that
come from src:android-platform-frameworks-base.
Instead of hard-wiring the dependencies in debian/control, my proposal was
to fix the version number in the various android-lib*.shlibs files so that
dh_shlibdeps would always do the right thing. You could do this in the
rules file similar to what has been done with dh_gencontrol for instance,
by introducing an override_dh_makeshlibs target and then using
dh_makeshlibs -pandroid-libbase -V "android-libbase (>= 1:$(DEB_VERSION))"
and similar statements for the other libraries of this source package.
Then it would no longer be necessary to have dependencies like this
Package: adb
Depends: ${misc:Depends}, ${shlibs:Depends}, android-libcutils (=
${binary:Version})
or like that
Package: android-libcutils
Depends: ${misc:Depends}, ${shlibs:Depends}, android-libbase (=
${binary:Version}), libbsd0
in debian/control. Normally, "Depends: ${misc:Depends}, ${shlibs:Depends}"
would just be enough.
Best regards,
Thomas Uhle
