[Android-tools-devel] Updating android-platform-system-core

[Hans-Christoph Steiner]

Markus Koschany:
> Hi,
> 
> Am 10.07.2015 um 18:42 schrieb 殷啟聰:
> [...]
>> 1. How should we define the version of the source package?
>> platform/dalvik produces tools belonging to both SDK Built-tools and
>> SDK Platform-tools, but this two toolsets have different version
>> numbers. Should we simply use "android-5.1.1_r6" as the version
>> number? Or "5.1.1~r6"?

We need to find the source of the "Android SDK Tools" 24.3.3. and "Android SDK
Build-tools" 22.0.1.


> I suppose r stands for (pre)release and the next "real" release will be
> 5.1.2 or similar. Then it makes sense to use 5.1.1~r6 because the number
> is smaller than 5.1.2. This is a common pattern in Debian.

As far as I understand it, that _r6 is actually a bugfix version, so like 5.1.1.6.

The tricky part of all this is that Google uses different version schemes for
the SDK and build tools.  For example, Android 5.1.1 is SDK android-22.
"Platform Tools" uses the SDK version e.g. 22.  Then the "Build Tools" uses
that SDK version as a major version with its own minor and bugfix versions.
But some parts of the SDK use a different major version, e.g "Android SDK
Tools v 24.3.3".  Its a mess...


>> 2. Why is the architecture of android-platform-system-core packages is
>> "linux-any" instead of "any"?

Upstream only supports GNU/Linux not GNU/Hurd or GNU/kFreeBSD.


> It seems the build failed at least on kfreebsd architectures.
> 
> https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64
> 
> This may be a temporary problem with the buildd, a bug in
> android-platform-system-core or upstream doesn't support
> freebsd/kfreebsd at all. I don't think the latter is true because I can
> find several Android related ports for FreeBSD, e.g.
> 
> https://www.freshports.org/devel/android-tools-adb/
> 
> So the decision to build only for Linux should be reconsidered.

There is still lots to be done, we don't need to get bogged down with details
like supporting non-Linux kernels.  We can leave the kFreeBSD porting to the
kFreeBSD people.  Let's get these packages working well for the vast majority
of people (Linux on amd64 and i386).


>> 3. Are executables looks for .so files recursively under /usr/lib/ or
>> /lib/ ? libzipfile.so and other Android libraries are placed under
>> /usr/lib/android/ but I do not see any specific configuration for
>> that.
> 
> You can find an dh_shlibdeps override in debian/rules. From the man page
> of dh_shlibdeps:
> 
>  -ldirectory[:directory ...]
> With recent versions of dpkg-shlibdeps, this option is generally not
> needed. It tells dpkg-shlibdeps (via its -l parameter), to look for
> private package libraries in the specified directory (or directories --
> separate with colons). With recent versions of dpkg-shlibdeps, this is
> mostly only useful for packages that build multiple flavors of the same
> library, or other situations where the library is installed into a
> directory not on the regular library search path.
> 
> 
>> 4. Why the .so version is 0.21.0? For example libzipfile.so.0.21.0,
>> why is it not libzipfile.so.21?
> 
> I guess that's a question for upstream because they define the
> versioning. :)
> 
> Regards,
> 
> Markus


I chose those versions.  Upstream does not build dynamic versions of those
libraries, but only statically links that code into each executable.  I used
0.21.0 to give room to set an 'epoch' as the first version number.  the 21 is
the SDK version. You can see that particular example here:

debian/patches/libandroidzipfile_makefile_pkgconfig

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20150710/fcbd96ca/attachment.sig>