<div dir="ltr">Hi Hans,<div><br></div><div>This is my overall plan. Assume that the latest release of Android is android-5.1.1_r8:</div><div><br></div><div>For every source package of Android repositories, we use 5.1.1.8 as the source version, so every executable and library of Android SDK will be versioned 5.1.1.8.</div><div><br></div><div>Then we have another source package "android-platform-development" based on platform/development which produces binary packages like androidsdk-common (or separated as androidsdk-platform-tools-common and so on) that install miscellaneous files belonging to each toolset. In <<a href="https://android.googlesource.com/platform/development/+/master/build/sdk.atree">https://android.googlesource.com/platform/development/+/master/build/sdk.atree</a>> we can see where to find the files to install for every SDK toolset.</div><div><br></div><div>Then we have three meta binary packages: androidsdk-platform-tools, android-sdk-build-tools and androidsdk-tools (which is why I suggested rename the existing androidsdk-tools), each of which depends on the tools and common files packages belonging to them. This three meta packages have their own versions following the original SDK version scheme. Thus androidsdk-build-tools can be versioned 22.1.3, androidsdk-platform-tools can be versioned 22.0.0 and androidsdk-tools can be versioned 24.2.3. We can make their depends versioned, for example androidsdk-platform-tools_22.0.0 depends on adb (>= 5.1.1.8), and maybe androidsdk-platform-tools_23.0.0 depends on adb (>= 6.0.0.1).</div><div><br></div><div>As of my observation, the minor part of the versions of androidsdk-tools and libgradle-android-java is the same, so I guess there will be no problem for them.</div><div><br></div><div>Cheers,</div><div>Kai-Chung Yan</div></div><br><div class="gmail_quote"><div dir="ltr">Hans-Christoph Steiner <<a href="mailto:hans@at.or.at">hans@at.or.at</a>> 於 2015年7月21日週二 上午6:17寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Got some useful advice from #debian-devel: binary packages can have separate<br>
versions from the source package using dpkg-gencontrol -v<br>
<br>
So in this case we can use the tag version for the source package in the<br>
debian/changelog, like this: 5.1.1+r7 (letters are allowed in versions).<br>
<a href="https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version" rel="noreferrer" target="_blank">https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version</a><br>
<br>
But it might still be easier to stick with the Build-tools versions since that<br>
means fewer binary packages will need to have their versions changed by<br>
dh_gencontrol.<br>
<br>
Also, we'll need to make meta-packages for android-platform-tools and<br>
android-build-tools anyway, so they can be separate source packages with their<br>
own versions, as needed.  These meta-packages do not contain files at all,<br>
just Depends:, Recommends: etc. and other control fields.<br>
<br>
.hc<br>
<br>
<br>
Hans-Christoph Steiner:<br>
><br>
> Oh what a big mess they've made of this.<br>
><br>
> My feeling is that we should use the Build-tools version as the source package<br>
> version since it is the most specific (e.g. 22.1.1) then if there are updates<br>
> that do not bump that version, the package version can be bumped (e.g.<br>
> 22.1.1-1, 22.1.1-2, etc)<br>
><br>
> Are there any utilities that use the same version number as Android OS<br>
> releases (e.g. 5.1.1)?  I have not seen any.<br>
><br>
> .hc<br>
><br>
> 殷啟聰:<br>
>> Hi Hans,<br>
>><br>
>> I agree on including a copy of AndroidConfig.h in android-platform-system<br>
>> and document it in README.debian or README.source, that makes sense.<br>
>><br>
>> On the version scheme, for example platform/dalvik, it produces hprof-conv<br>
>> for Platform-tools and dx for Build-tools, which will have different<br>
>> versions according to SDK version scheme, then we have trouble versioning<br>
>> the source package android-platform-dalvik.<br>
>><br>
>> Also, if you look at the difference between android-5.1.1_r7 and<br>
>> android-5.1.1_r8 of platform/system/core (see <<br>
>> <a href="https://github.com/android/platform_system_core/compare/android-5.1.1_r7...android-5.1.1_r8" rel="noreferrer" target="_blank">https://github.com/android/platform_system_core/compare/android-5.1.1_r7...android-5.1.1_r8</a>>),<br>
>> you can find that even 2 minor point release of Android have differences on<br>
>> the codes. But if you check out this 2-tag-differences on<br>
>> platform/development (see <<br>
>> <a href="https://github.com/android/platform_development/compare/android-5.1.1_r7...android-5.1.1_r8" rel="noreferrer" target="_blank">https://github.com/android/platform_development/compare/android-5.1.1_r7...android-5.1.1_r8</a>>),<br>
>> Neither the version of Platform-tools nor Build-tools has changed. This<br>
>> means we can't deliver the latest tools in Android SDK if we only stick<br>
>> with the SDK version scheme, also we don't know which exact tag corresponds<br>
>> to SDK version 22.<br>
>><br>
>> In the future we will also package the emulator which will be complicated<br>
>> as well, so following Android versions is the best solution of following<br>
>> upstream. We can still find the SDK versions in platform/development under<br>
>> the specific tags, and we will document that in README.source/README.debian<br>
>> and the package description.<br>
>><br>
>> Cheers,<br>
>> Kai-Chung Yan<br>
>><br>
>> Hans-Christoph Steiner <<a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a>> 於 2015年7月18日週六 上午12:07寫道：<br>
>><br>
>>><br>
>>><br>
>>> 殷啟聰:<br>
>>>> Hi,<br>
>>>><br>
>>>> I found another circular dependencies! zipalign in android-platform-build<br>
>>>> requires libcutils.so in android-platform-system while<br>
>>>> android-platform-system build-depends on AndroidConfig.h in<br>
>>>> android-platform-build.<br>
>>><br>
>>> Arg, why on earth did they move AndroidConfig.h?  What a pain.  I think we<br>
>>> should just include a copy of all the AndroidConfig.h (i.e.<br>
>>> core/combo/include/arch) in android-platform-system and document that in<br>
>>> debian/README.Source.<br>
>>><br>
>>> Then android-platform-build should make core/combo/include in a separate<br>
>>> package, like you said before.<br>
>>><br>
>>><br>
>>>> About the version scheme, I still insist using 5.1.1.8 instead. These<br>
>>>> various repo do not only contain the SDK programs, instead they are<br>
>>>> actually the core components of Android. For example platform/dalvik<br>
>>> which<br>
>>>> contains dx, is the apparently the code base of Dalvik Virtual Machine.<br>
>>> As<br>
>>>> for platform/system/core, it is the minimal boot environment of Android<br>
>>> as<br>
>>>> is written. So the best solution is to follow the entire Android version<br>
>>>> number.<br>
>>><br>
>>> It is true that these git repos include a mix of SDK Tools and components<br>
>>> of<br>
>>> Android OS. We are not building the core components of Android itself,<br>
>>> we're<br>
>>> building the SDK Tools and SDK.  Upstream also builds the SDK Tools and<br>
>>> Android from the same git repos, and yet upstream gives the SDK Tools<br>
>>> separate<br>
>>> version numbers from Android OS.<br>
>>><br>
>>><br>
>>>> If you check the git history you can find that even the "SDK version" has<br>
>>>> remains 22 but the codes have changed a lot. Also, if you simply ignore<br>
>>> the<br>
>>>> minor part in 22.1.3 (Build-tools version) and simply use 22 for both<br>
>>>> toolsets, some day Google may have released 22.1.4 and the users still<br>
>>> has<br>
>>>> the old version because we have ignored the difference.<br>
>>><br>
>>> We should do what upstream does.  For Build-tools, it is obvious that they<br>
>>> make minor (22, 22.1, etc.) and bugfix releases (22.1.1, 22.1.2, etc.).<br>
>>> For<br>
>>> "Android SDK Platform-tools", the only make major releases (20, 21, 22)<br>
>>> though<br>
>>> they have recently starting doing RC (23 rc4).  Its an insane system for<br>
>>> sure,<br>
>>> but if we don't follow it in Debian, it will confuse users when they are<br>
>>> comparing to the official releases from Google.<br>
>>><br>
>>> We need to track these SDK versions anyway, since<br>
>>> /usr/share/android-sdk/build-tools needs to have versioned subdirectories.<br>
>>><br>
>>> .hc<br>
>>><br>
>>>><br>
>>>> Cheers,<br>
>>>> Kai-Chung Yan<br>
>>>><br>
>>>> 2015 年 7 月 17 日 (週五)12:15 <Hans-Christoph Steiner> 於 <a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a> 寫道：<br>
>>>><br>
>>>>><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:<br>
>>>>> <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:<br>
>>>>> <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>
>>>>><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>
>>>>>> <<br>
>>>>><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<br>
>>> quite<br>
>>>>> close, then I think the best approach would be to make the Debian<br>
>>> packages<br>
>>>>> include those libraries.  If Android uses old versions or doesn't update<br>
>>>>> 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<br>
>>> "1:5.1.1.8".<br>
>>>>> 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<br>
>>>>> 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>
>>>>>>>><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<br>
>>> 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<br>
>>>>> "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<br>
>>>>> be<br>
>>>>>>>>> 5.1.2 or similar. Then it makes sense to use 5.1.1~r6 because the<br>
>>>>> 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<br>
>>>>> like<br>
>>>>>>>> 5.1.1.6.<br>
>>>>>>>><br>
>>>>>>>> The tricky part of all this is that Google uses different version<br>
>>>>> schemes<br>
>>>>>>>> for<br>
>>>>>>>> the SDK and build tools.  For example, Android 5.1.1 is SDK<br>
>>> android-22.<br>
>>>>>>>> "Platform Tools" uses the SDK version e.g. 22.  Then the "Build<br>
>>> 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<br>
>>>>> SDK<br>
>>>>>>>> Tools v 24.3.3".  Its a mess...<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>>> 2. Why is the architecture of android-platform-system-core packages<br>
>>>>> 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>
>>>>>>>>><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<br>
>>>>> 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<br>
>>>>> 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/<br>
>>> 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<br>
>>>>> 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>
>>>>> --<br>
>>>>>>>>> separate with colons). With recent versions of dpkg-shlibdeps, this<br>
>>> is<br>
>>>>>>>>> mostly only useful for packages that build multiple flavors of the<br>
>>>>> 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<br>
>>>>> those<br>
>>>>>>>> libraries, but only statically links that code into each<br>
>>> executable.  I<br>
>>>>>>>> used<br>
>>>>>>>> 0.21.0 to give room to set an 'epoch' as the first version number.<br>
>>>>> 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>
>>>>><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>