[Android-tools-devel] Using Profile Builds instead of Merging Repos for Resolving Circular Dependencies among AOSP Packages

[殷啟聰]

Hi Hans,

I'll start preparing the AOSP packages using Profile Builds and
pushing changes to android-platform-system-core and
android-platform-system-extras. I will change these 2 repos to use
traditional import-orig method. Here is how we upload these AOSP
packages:

1. We prepare the stage1 version. Thus we will have packages like
android-platform-system-core_6.0.0+r26-1~stage1. These packages differ
to the full version in that they won't build all binary packages.
2. Upload the packages.
3. We wait till ftp-master accepts all of them and buildd on all other
ports have installed them.
4. We prepare the full version like
android-platform-system-core_6.0.0+r26-1, and upload it.

To prepare a stage1 package, we need to specify the build profiles in
the shell environment in order to build for some stage, but buildd
doesn't support automatically building multiple profiles, so we can
set the profile in debian/rules, and remove all Build-Depends that are
not stage1.

Typically these steps are only needed when we are uploading some fresh
new packages. After they are uploaded to Debian archive, we don't need
to do staged uploads again if we are updating them in the future.

So actually the very first package we need to upload is
android-platform-build_6.0.0+r26-1~stage1, since all AOSP depends on
the AndroidConfig.h it produces, an the stage1 only produces this
package.

Hans, do you have other ideas?

Regards,
Kai-Chung Yan

2015-11-16 21:39 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>
> Hey Kai-Chung,
>
> Thanks for your research on this!  It sounds like the profile builds approach
> is the way forward.  It is definitely worth putting in work up front if that
> lowers the maintenance load.  I am not familiar with Profile Builds, so I
> can't really help figure out the details.  But let me know what you need me to
> do to make this happen.
>
> .hc
>
> 殷啟聰:
>> Hi all,
>>
>> Currently we have prepared many packages for producing an entire
>> Android SDK which are hosted on Alioth. The problem is that these ASOP
>> upstream repositories have complicated dependencies between one
>> another including several circular dependencies. The attachment is a
>> graph I made to present you the relationships between these
>> repositories where the reverse directions of the arrows represent the
>> dependencies, e.g. at the top, platform/frameworks/base depends on
>> platform/frameworks/native. We can also see that all repositories
>> depend on platform/build because all ASOP C/C++ sources must include
>> AndroidConfig.h in platform/build, and most repositories depend on
>> platform/system/core because most of them link against liblog.so in
>> it.
>>
>> For now the solution is simply merging all repositories with circular
>> dependencies into one source package. Here are the merged packages:
>>
>>   * android-platform-system:
>>     - platform/system/core
>>     - platform/system/extras
>>     - platform/libnativehelper
>>     - platform/build
>>   * android-platform-frameworks-compile
>>     - platform/frameworks/compile/libbcc
>>     - platform/frameworks/compile/slang
>>     - platform/frameworks/rs
>>
>> Some days ago pabs reminded me the concept of Profile Builds which is
>> described in <https://wiki.debian.org/DebianBootstrap>. Using Profile
>> Builds we can break the circular dependencies without merging them
>> together. I have made some changes to android-platform-build in the
>> "profile-builds" branch
>> <http://anonscm.debian.org/cgit/android-tools/android-platform-build.git/tree/?h=profile-builds>
>> to use Profile Builds. The key changes are d/rules and d/control.
>> However if we use Profile Builds the process of uploading to Debian is
>> a little bit complicated, because buildd currently doesn't support
>> Profile Builds, the packages on other ports will fail to build. Here
>> is the estimated process from my understanding:
>>
>>   1. Build android-platform-system-core,
>> android-platform-system-extras, android-platform-libnativehelper,
>> android-platform-build in stage1. In stage1 they are configured to be
>> able to built independently.
>>   2. Install the needed packages produced by those 4 source packages in stage1.
>>   3. Build those 4 source packages without specifying a build profile.
>>   4. Upload them to FTP Master.
>>   5. Fire binNMUs for all other ports.
>>
>> Actually these steps are only needed in the first ever upload. When
>> some day we are preparing packages for Android 7, all packages should
>> be installed in all ports by then, we can simply upload them and most
>> of them can be built automatically.
>>
>> After all I personally don't like the merging because it's complicated
>> to reproduce the source tarball and the structure will be a mess. If
>> we gradually find more circular dependencies in the future, that means
>> we need to merge more repositories into one packages and it gets
>> bigger and bigger.
>>
>> Regards,
>> Kai-Chung Yan
>>



-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Full-time student of National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <seamlik.logdown.com>
*/