<p dir="ltr">Hi,</p>
<p dir="ltr">I found another circular dependencies! zipalign in android-platform-build requires libcutils.so in android-platform-system while android-platform-system build-depends on AndroidConfig.h in android-platform-build.</p>
<p dir="ltr">About the version scheme, I still insist using 5.1.1.8 instead. These various repo do not only contain the SDK programs, instead they are actually the core components of Android. For example platform/dalvik which contains dx, is the apparently the code base of Dalvik Virtual Machine. As for platform/system/core, it is the minimal boot environment of Android as is written. So the best solution is to follow the entire Android version number.</p>
<p dir="ltr">If you check the git history you can find that even the "SDK version" has remains 22 but the codes have changed a lot. Also, if you simply ignore the minor part in 22.1.3 (Build-tools version) and simply use 22 for both toolsets, some day Google may have released 22.1.4 and the users still has the old version because we have ignored the difference.</p>
<p dir="ltr">Cheers,<br>
Kai-Chung Yan</p>
<br><div class="gmail_quote"><div dir="ltr">2015 年 7 月 17 日 (週五)12:15 <Hans-Christoph Steiner> 於 <a href="mailto:hans@at.or.at">hans@at.or.at</a> 寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
殷啟聰:<br>
> Hi,<br>
><br>
> I am currently working on a new source package<br>
> "android-platform-system" based on "android-platform-system-core", and<br>
> another new source package "android-platform-build". They are<br>
> currently on GitHub:<br>
><br>
> * android-platform-system: <a href="https://github.com/seamlik/android-platform-system" rel="noreferrer" target="_blank">https://github.com/seamlik/android-platform-system</a><br>
> * android-platform-build: <a href="https://github.com/seamlik/android-platform-build" rel="noreferrer" target="_blank">https://github.com/seamlik/android-platform-build</a><br>
<br>
android-platform-build already exists, it should be updated:<br>
<a href="https://anonscm.debian.org/cgit/android-tools/android-platform-build.git" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/android-tools/android-platform-build.git</a><br>
<br>
<br>
> Currently android-platform-build only produces one binary package:<br>
> android-globalconfig-dev, which installs AndroidConfig.h for all<br>
> architectures originating from<br>
> <<a href="https://android.googlesource.com/platform/build/+/master/core/combo/arch" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/build/+/master/core/combo/arch</a>><br>
> to /usr/include/android/. The upstream of the source package is simply<br>
> platform/build. These AndroidConfig.h must be included in all Android<br>
> C/C++ libraries so it makes sense to become a separated package.<br>
> Packages like android-platform-system and android-platform-dalvik<br>
> should build-depends on it.<br>
><br>
> However the mechanism of selecting which AndroidConfig.h to use is<br>
> rather unreliable for now. It uses uname -m to determine the<br>
> architecture currently, but I will use dpkg-architecture in the<br>
> future. Do you have a better idea?<br>
><br>
> Currently android-platform-system consists of platform/system/core and<br>
> platform/system/extra. The reason I chose not to make separated ones<br>
> is the circular dependencies between them if they are separated. For<br>
> example, fastboot requires f2fs_utils (in platform/system/extra), and<br>
> f2fs_utils requires libsparse (in platform/system/core). There are<br>
> more components under platform/system/ but it is good to include this<br>
> two for now, maybe we will need to include others like<br>
> platform/system/bluetooth in the future.<br>
><br>
> I also restructured the Debian codes so that every modules<br>
> android-platform-system produces uses an individual .mk file, and they<br>
> are not managed by Quilt.<br>
<br>
That's a nice system. :)<br>
<br>
<br>
> However there is a problem now. f2fs_utils requires another libraries<br>
> from upstream f2fs-tools and e2fsprogs which are external projects<br>
> (also available at<br>
> <a href="https://android.googlesource.com/platform/external/f2fs-tools" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/external/f2fs-tools</a> and<br>
> <a href="https://android.googlesource.com/platform/external/e2fsprogs" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/external/e2fsprogs</a>) and<br>
> available in Debian as well (See<br>
> <a href="https://packages.debian.org/source/sid/f2fs-tools" rel="noreferrer" target="_blank">https://packages.debian.org/source/sid/f2fs-tools</a> and<br>
> <a href="https://packages.debian.org/source/sid/e2fsprogs" rel="noreferrer" target="_blank">https://packages.debian.org/source/sid/e2fsprogs</a>). But none of their<br>
> Debian versions contains the libraries f2fs_utils requires. It<br>
> requires      .so from e2fsprogs and libf2fs_format.so from<br>
> f2fs-tools.<br>
><br>
> The best and ideal solution is to contact with their maintainers in<br>
> Debian and make the packages produce those libraries, but it may take<br>
> a long time and the required libraries may be simply unnecessary for<br>
> the upstream. The second solution is to check the upstream and the<br>
> Debian sources and see if the upstream's main libraries has already<br>
> included all APIs in libext2_uuid.so and libf2fs_format.so, but I<br>
> guess it is rather unlikly. The third solution is to make another new<br>
> source package "android-platform-external" which consist of<br>
> platform/external/f2fs-tools and platform/external/e2fsprogs. This<br>
> solution is the easiest and fastest one but I don't know if it breaks<br>
> any Debian policies.<br>
><br>
> What are you opinion?<br>
<br>
If the versions of f2fs-tools and e2fsprogs in Android and Debian are quite<br>
close, then I think the best approach would be to make the Debian packages<br>
include those libraries.  If Android uses old versions or doesn't update much,<br>
then I think the android-platform-external approach is better.<br>
<br>
.hc<br>
<br>
<br>
><br>
> Cheers,<br>
> Kai-Chung Yan<br>
><br>
> 2015-07-11 20:12 GMT+08:00 殷啟聰 <<a href="mailto:seamlikok@gmail.com" target="_blank">seamlikok@gmail.com</a>>:<br>
>> Hi,<br>
>><br>
>> So far we have 2 options of defining the version of android-platform-*<br>
>> source packages. Suppose we are fetching sources with tag<br>
>> "android-5.1.1_r8", then the source version can be "22" or "1:5.1.1.8". The<br>
>> former may be  incorrect to some extent because the version of SDK<br>
>> Build-tools is 22.1.3 but the version of SDK Platform-tools is 22.0.0 which<br>
>> do not match. Therefore I prefer "1:5.1.1.8" which seems odd though.<br>
>><br>
>> Although androidsdk-tools is good to remain the version scheme.<br>
>><br>
>> I am also thinking of installing symlinks to the tools in<br>
>> /usr/share/android-sdk/ which serves as the pseudo SDK installation<br>
>> location.<br>
>><br>
>> Cheers,<br>
>> Kai-Chung Yan<br>
>><br>
>><br>
>> 2015 年 7 月 11 日 (週六)14:31 <Hans-Christoph Steiner> 於 <a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a> 寫道：<br>
>>><br>
>>><br>
>>> Markus Koschany:<br>
>>>> Hi,<br>
>>>><br>
>>>> Am 10.07.2015 um 18:42 schrieb 殷啟聰:<br>
>>>> [...]<br>
>>>>> 1. How should we define the version of the source package?<br>
>>>>> platform/dalvik produces tools belonging to both SDK Built-tools and<br>
>>>>> SDK Platform-tools, but this two toolsets have different version<br>
>>>>> numbers. Should we simply use "android-5.1.1_r6" as the version<br>
>>>>> number? Or "5.1.1~r6"?<br>
>>><br>
>>> We need to find the source of the "Android SDK Tools" 24.3.3. and "Android<br>
>>> SDK<br>
>>> Build-tools" 22.0.1.<br>
>>><br>
>>><br>
>>>> I suppose r stands for (pre)release and the next "real" release will be<br>
>>>> 5.1.2 or similar. Then it makes sense to use 5.1.1~r6 because the number<br>
>>>> is smaller than 5.1.2. This is a common pattern in Debian.<br>
>>><br>
>>> As far as I understand it, that _r6 is actually a bugfix version, so like<br>
>>> 5.1.1.6.<br>
>>><br>
>>> The tricky part of all this is that Google uses different version schemes<br>
>>> for<br>
>>> the SDK and build tools.  For example, Android 5.1.1 is SDK android-22.<br>
>>> "Platform Tools" uses the SDK version e.g. 22.  Then the "Build Tools"<br>
>>> uses<br>
>>> that SDK version as a major version with its own minor and bugfix<br>
>>> versions.<br>
>>> But some parts of the SDK use a different major version, e.g "Android SDK<br>
>>> Tools v 24.3.3".  Its a mess...<br>
>>><br>
>>><br>
>>>>> 2. Why is the architecture of android-platform-system-core packages is<br>
>>>>> "linux-any" instead of "any"?<br>
>>><br>
>>> Upstream only supports GNU/Linux not GNU/Hurd or GNU/kFreeBSD.<br>
>>><br>
>>><br>
>>>> It seems the build failed at least on kfreebsd architectures.<br>
>>>><br>
>>>><br>
>>>> <a href="https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64" rel="noreferrer" target="_blank">https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64</a><br>
>>>><br>
>>>> This may be a temporary problem with the buildd, a bug in<br>
>>>> android-platform-system-core or upstream doesn't support<br>
>>>> freebsd/kfreebsd at all. I don't think the latter is true because I can<br>
>>>> find several Android related ports for FreeBSD, e.g.<br>
>>>><br>
>>>> <a href="https://www.freshports.org/devel/android-tools-adb/" rel="noreferrer" target="_blank">https://www.freshports.org/devel/android-tools-adb/</a><br>
>>>><br>
>>>> So the decision to build only for Linux should be reconsidered.<br>
>>><br>
>>> There is still lots to be done, we don't need to get bogged down with<br>
>>> details<br>
>>> like supporting non-Linux kernels.  We can leave the kFreeBSD porting to<br>
>>> the<br>
>>> kFreeBSD people.  Let's get these packages working well for the vast<br>
>>> majority<br>
>>> of people (Linux on amd64 and i386).<br>
>>><br>
>>><br>
>>>>> 3. Are executables looks for .so files recursively under /usr/lib/ or<br>
>>>>> /lib/ ? libzipfile.so and other Android libraries are placed under<br>
>>>>> /usr/lib/android/ but I do not see any specific configuration for<br>
>>>>> that.<br>
>>>><br>
>>>> You can find an dh_shlibdeps override in debian/rules. From the man page<br>
>>>> of dh_shlibdeps:<br>
>>>><br>
>>>>  -ldirectory[:directory ...]<br>
>>>> With recent versions of dpkg-shlibdeps, this option is generally not<br>
>>>> needed. It tells dpkg-shlibdeps (via its -l parameter), to look for<br>
>>>> private package libraries in the specified directory (or directories --<br>
>>>> separate with colons). With recent versions of dpkg-shlibdeps, this is<br>
>>>> mostly only useful for packages that build multiple flavors of the same<br>
>>>> library, or other situations where the library is installed into a<br>
>>>> directory not on the regular library search path.<br>
>>>><br>
>>>><br>
>>>>> 4. Why the .so version is 0.21.0? For example libzipfile.so.0.21.0,<br>
>>>>> why is it not libzipfile.so.21?<br>
>>>><br>
>>>> I guess that's a question for upstream because they define the<br>
>>>> versioning. :)<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Markus<br>
>>><br>
>>><br>
>>> I chose those versions.  Upstream does not build dynamic versions of those<br>
>>> libraries, but only statically links that code into each executable.  I<br>
>>> used<br>
>>> 0.21.0 to give room to set an 'epoch' as the first version number.  the 21<br>
>>> is<br>
>>> the SDK version. You can see that particular example here:<br>
>>><br>
>>> debian/patches/libandroidzipfile_makefile_pkgconfig<br>
>>><br>
>>> .hc<br>
>>><br>
>> --<br>
>><br>
>> 殷啟聰 | Kai-Chung Yan<br>
>> 一生只向真理與妻子低頭<br>
>> Full-time student of Providence University of Taiwan<br>
>> LinkedIn: <<a href="https://linkedin.com/in/seamlik" rel="noreferrer" target="_blank">https://linkedin.com/in/seamlik</a>><br>
>> Blog: <<a href="http://seamlik.logdown.com" rel="noreferrer" target="_blank">seamlik.logdown.com</a>><br>
><br>
><br>
><br>
</blockquote></div><div dir="ltr">-- <br></div><p dir="ltr">殷啟聰 | Kai-Chung Yan<br>
一生只向真理與妻子低頭<br>
Full-time student of National Taichung University of Education<br>
LinkedIn: <<a href="https://linkedin.com/in/seamlik">https://linkedin.com/in/seamlik</a>><br>
Blog: <<a href="http://seamlik.logdown.com">seamlik.logdown.com</a>></p>