Re: building platform-tools without splitting out dependencies (e.g. boringssl)
Dear Chirayu,
Thanks for the latest releasing info from upstream!
On Thu, Jul 14, 2022 at 6:52 AM Chirayu Desai <chirayudesai1@gmail.com> wrote:
>
> Google released Android 13 Beta 4 a few hours ago. - https://android-developers.googleblog.com/2022/07/Final-Android-13-Beta-update-official-release-is-next.html
>
> The tag is up, "android-t-beta-4-gpl" GPL is mentioned specifically, and if you check the manifest, only those projects are listed.
>
> https://android.googlesource.com/platform/manifest/+/6ece7034386e049fac937538b827a6dd99764122/default.xml
>
> It's announced on their "android-building" mailing list, see https://groups.google.com/g/android-building/c/t8ZMqo8-zR8
>
> It says "Today, we pushed a small number of GPL projects for the Android T Developer Beta 3.2.
> The tag is android-t-beta-3.2-gpl. It is not a full platform update and only for reference." for the previous tag (beta 4 note might be visible in a few hours)
Yes, I agree that tag android-{VER}-gpl is a new toy from upstream,
and we should ignore it currently.
We'll see whether and how to use it when things get clear after they
release a few more times.
BTW.
Currently -gpl manifest is almost all external repositories, which
seems not useful to our Debian packaging team.
> I've been working on Android / AOSP for about 10 years now, and it has always been like this for every release. We should get proper full 13 source code sometime next month in August - android-13.0.0_r1 and such tags will be available then.
>
> Which is why I recommend not using these tags even if they're the newest - they're only for reference.
The purpose to Use X~{preview,beta}Y is to start packing as early as
possible for the next version of android major version.
If we wait for the real official release, we will miss the Debconf,
miss the GSoC project.
Debconf audience just get to know some old info of Android last year,
while GSoC students just work on the old version.
I don't think this is good for anyone.
(maybe that's also the reason why Debian version is behind upstream
for the past few years.)
And, starting to package the X~{preview,beta}Y version does not mean
we ignore the official release.
When upstream release, we can immediately migrate our packaging work
to latest, and the effort is very little, since the gap between
preview/beta and official release is just bug fixing, no major API
breakage.
Yes, you can say such preview/beta stuff is not suitable for unstable,
and only suitable for experimental.
I agree with this. We can have a packaging rule about it, if you also agree.
Cheers,
Roger
> On Mon, Jul 11, 2022 at 5:51 PM Hans-Christoph Steiner <hans@guardianproject.info> wrote:
>>
>>
>>
>> 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: