Package: android-libandroidfw
Version: 1:14~beta1-2
Severity: serious
User: debian-arm@lists.debian.org
Usertags: time-t

Hi Umang,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
android-libandroidfw as a package shipping a library whose ABI changes on
32-bit architectures with 64-bit time_t.

However, android-libandroidfw's shlibs file declares a dependency on a
library package name that contains no ABI information:

$ cat DEBIAN/shlibs
libandroidfw 0 android-libandroidfw
$

It is therefore not obvious that we should rename the package to
'android-libandroidfwt64' as part of this transition.

Looking at the archive, there are packages that depend on this library, aapt
and split-select.  Despite being built from the same source package, they do
not have a strict versioned dependency on android-libandroidfw but instead
use the shlibs.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading android-libandroidfw without also
upgrading aapt, split-select) will result in ABI skew and may result in
broken behavior.

Thanks,

control: severity -1 normal

related to #1062209, and #1062110
so aligning with the same way to the bug report.

[ copy the email from Hans ]

Thanks for reporting!  In the Android Tools case, the shared libs and packages
that use them are packaged together, often from the same source package, so I
can't see why we'd need special versions of it. And when we need to, we can use
strictly versioned depends, so it should be fine. I'm going to set the bug to
normal for now.

strictly versioned depends, but they are not:

Package: aapt
Source: android-platform-frameworks-base (1:14~beta1-2)
Depends: android-libaapt, android-libandroidfw, [...]

At least I don't see an "(= 1:14~beta1-2)" constraint here.

Seems like you need to change the package relationships first.

Chris

Oh, and while you can do that going forward, you also need to
break/conflict with all old versions.

Maybe you should rethink if this is a good strategy.

Chris

Dear Chris,

Thanks for your interests in android related packages!
same package.

Do you have other ideas? Please let me know if you have better way
out. Thank you!

Cheers,
Roger

Roger,

* Roger Shimizu <rogershimizu@gmail.com> [240826 10:30]:

aapt and android-libaapt and android-libandroidfw are built from the
same source package, I think?

If there are other packages involved, then this is not an option
indeed.

Well, the bug is about android-libaapt, android-libandroidfw
changing their ABI when recompiled on time_t-64-transitioned
architectures, like armel and armhf.

Without any package relationship changes, it is assumed that this
will cause (best case) crashes and/or (worst case) data corruption
or loss.

I think there are a few options:

1) Investigate if the ABI really changes. If not, then you can just
close this bug report.

2) If the ABI changes, you need to make sure users cannot run into
the resulting bugs.

2a) Most of the archive dealt with this by renaming the library
packages and changing the corresponding Depends:, etc. Please see
the wiki page about the transition for this.

2b) Some packages intead adopted a dual-ABI strategy. They provide
the old ABI and the new ABI, usually by having two symbols (old and
new).

2c) Find some other way of enforcing strong package relationships.
Hans' mail seems to say that this is what they wanted to do? But
it doesn't look like this has happened.

2d) I *guess* if you can't make this work at all, you could also
remove the packages from all time_t-64-transitioned architectures (=
all 32-bit except i386). Not sure if that would be politically
acceptable.

Best,
Chris