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

[Hans-Christoph Steiner]

Sounds good overall.  There is one key detail that needs to be worked
out: all 6.0.0 packages need to be built against 6.0.0 packages.  Does
the profile builds handle that?  I guess perhaps we should set the
depends and build-depends to have the same versions across all packages
to enforce that, if need be.

For something like android-platform-build, its already in Debian, so it
won't need to go through the NEW queue unless some new binary packages
are being made in the process.

We can upload all of this to experimental so we don't have to undo
anything if there is breakage or problems.  Its easy to move packages
from experimental to unstable, so no big deal there.

.hc

殷啟聰:
> 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
>>>
> 
> 
>