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

[殷啟聰]

Hi,

So far we have 2 options of defining the version of android-platform-*
source packages. Suppose we are fetching sources with tag
"android-5.1.1_r8", then the source version can be "22" or "1:5.1.1.8". The
former may be  incorrect to some extent because the version of SDK
Build-tools is 22.1.3 but the version of SDK Platform-tools is 22.0.0 which
do not match. Therefore I prefer "1:5.1.1.8" which seems odd though.

Although androidsdk-tools is good to remain the version scheme.

I am also thinking of installing symlinks to the tools in
/usr/share/android-sdk/ which serves as the pseudo SDK installation
location.

Cheers,
Kai-Chung Yan

2015 年 7 月 11 日 (週六)14:31 <Hans-Christoph Steiner> 於 hans at at.or.at 寫道：

>
> 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
>
> --

殷啟聰 | Kai-Chung Yan
一生只向真理與妻子低頭
Full-time student of Providence University of Taiwan
LinkedIn: <https://linkedin.com/in/seamlik>
Blog: <seamlik.logdown.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20150711/c0d3c576/attachment.html>