I'm sure Debian has reasons for doing it that way but the undeniable consequence is that they made a decision that resulted in more complicated package updates.

I'm sure Debian has reasons for doing it that way but the undeniable consequence is that they made a decision that resulted in more complicated package updates. I'm used to Arch Linux where, for the most part, you can just download a PKGBUILD, increment the version number and you're done. Have a look at Arch [0] vs. Debian [1]. Arch's package specification just tells the build tools where to get the code and how to build it. Debian's includes all the code so the repository has to be updated first (which I tried, resulting in merge conflicts). Perhaps this approach has advantages (like not relying on the third party code hosting) but it also comes with disadvantages. I have no ill feelings towards the Debian project or its contributors but they are responsible for the choice that led to the issue I have, so I feel it's entirely reasonable to "blame" them (I don't feel that's the right word, they just made a tradeoff that is inconvenient to me but might make sense to them). [0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/android-tools https://git.archlinux.org/svntogit/community.git/tree/trunk/... [1]: https://salsa.debian.org/android-tools-team/android-platform-build https://salsa.debian.org/android-tools-team/android-platform...