Re: building platform-tools without splitting out dependencies (e.g. boringssl)
Dear Chirayu and Hans-Christoph,
Sorry for the late reply.
I was travelling to DebConf, and now I just arrived at the venue.
For the topic you mentioned, I have some comments.
I think using manifest XML to bundle the source is a workaround, and
currently there's no better solution.
In other words, it's best practice so far.
On the other hand, splitting boringssl out is because:
- boringssl API is not as volatile as other libraries.
For example, android-platform-tools/29.0.6 can still use
boringssl/10.0.0+r36-1 (in bullseye)
I previously just uploaded android-platform-tools/29.0.6-19 to
bullseye-backports without backport boringssl, all autopkgtest passed.
And android-platform-tools/29.0.6 is currently using boringssl/13~preview2-7
- Boringssl technically can support all little-endian Arch:
* https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/base.h#124
But due to the android-platform-tools cannot be built for so many
Arch, we cannot run unit test / autopkgtest to check whether it works.
Splitting boringssl out makes these all possible, and now we can see
the result of unit test in build log (dh_auto_test part):
* https://buildd.debian.org/status/package.php?p=android-platform-external-boringssl
- It might be beneficial to other projects from google, like chromium.
Of course, if boringssl breaks API someday, we can fallback to
bundling into manifest then.
> Google releases major versions of Android on a yearly schedule - there are preview builds before that, those are not fully open source.
>
> However, android includes various GPL code, for which they do need to release the source code, and they just tag all projects, most of which don't correspond to the actual source code used. So we've always avoided preview tags.
>
> The latest platform-tools tag is https://android.googlesource.com/platform/manifest/+/refs/heads/platform-tools-33.0.1 - and we would like to update platform-tools to that.
I think if we breakdown the "release" into categories, you will find:
- android-{version} tag release is far behind platform-tools-{version} tag
- platform-tools-{version} tag usually lead about 6 months earlier, I
guess because need to release to public, so vendors can use it to
connect to prototype devices.
- For example, platform-tools-33.0.1 released, but no android-13.x
release, but only android-t-{preview,beta} tag released. While
android-12.x was based on 12 months older version of Android.
Basically android-t-{preview,beta} is the latest, and something before
official android-13.x tag.
That's why I created 13~preview version, to meet with debian versioning rules.
Hope it explains the confusion caused.
Cheers,
Roger
On Thu, Jul 7, 2022 at 10:40 PM Chirayu Desai <chirayudesai1@gmail.com> wrote:
>
> Hey rosh,
>
> Thanks for all your work maintaining these packages.
>
> Another thing I'd like to add is that the preview tags aren't very useful.
>
> Google releases major versions of Android on a yearly schedule - there are preview builds before that, those are not fully open source.
>
> However, android includes various GPL code, for which they do need to release the source code, and they just tag all projects, most of which don't correspond to the actual source code used. So we've always avoided preview tags.
>
> The latest platform-tools tag is https://android.googlesource.com/platform/manifest/+/refs/heads/platform-tools-33.0.1 - and we would like to update platform-tools to that.
>
> On Thu, Jul 7, 2022 at 6:52 PM Hans-Christoph Steiner <hans@guardianproject.info> wrote:
>>
>>
>> Hey rosh,
>>
>> Thanks for all your ongoing work with the Android Tools packages! I wanted to
>> ask you something about the *-platform-tools package. After years of trying to
>> split out upstream source repos into Debian packages, Chirayu led the charge on
>> a new approach of building based on how upstream does it, with statically
>> linking in all the dependencies. Although this sucks compared to how Debian
>> manages dependencies, it has proven to be a ton of work to do things differently
>> with the Android Tools packages. Other packages with builds like this, Chromium
>> for example, now also do this. Otherwise, we can't keep up with updates from
>> upstream.
>>
>> So we recently saw that you split out the boringssl dependency from the
>> -platform-tools package. boringssl is a classic example of why we have to build
>> like upstream does. boringssl does not have releases at all. Projects that use
>> boringssl pin to a specific commit, and all new work is just merged to the main
>> branch. That means that sharing boringssl binaries between projects could break
>> things, since the projects could require different commits of boringssl.
>>
>> .hc
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
Reply to: