[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: building platform-tools without splitting out dependencies (e.g. boringssl)





Roger Shimizu:
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

I also thought this approach was important to try. Indeed, that is how the Android Tools have been structured for years now. The new manifest approach has so far proven itself to be much less work for updates.

- 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

We cannot keep up with the maintenance load we already have. Supporting more archs will make that situation worse, especially if the porting is happening in Debian. I think we need to stick to the upstream archs until it is proven that we can keep up with the packages as they are.

- 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.

They do break the API from time to time because the boringssl maintainers and all the projects using boringsll are built around using master, and making code changes whenever they update boringssl. Upstream uses the giant single repo workflow (via "repo", Piper, etc) where all the code, including external dependencies, are edited at the same time. The chromium maintainers are the in same boat as us: they can barely keep up with the maintenance load as is it. Using an external boringssl will increase the maintenance load, and that could mean that we no longer have Chromium in Debian.


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.

Thanks for the info. I'm pretty sure we want to stick to the platform-tools-{version} tags now, at least for the platform-tools package.

.hc


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

--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556


Reply to: