[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1

[Hans-Christoph Steiner]

Markus Koschany:
> On 27.05.2016 16:37, 殷啟聰 wrote:
>> Hi,
>>
>> I have prepared a new version of android-platform-libcore. The changelog is:
> [...]
>>
>>   [ Kai-Chung Yan ]
>>   * New package: android-platform-libcore-source
> [...]
> 
> Hi,
> 
> my main concern is still that the package is actually named
> android-platform-libcore-source-6.0.1. This may be intentional but we
> should try to find a better way or at least list all available options
> and then decide the best way forward.
> 
> Versions in binary packages is something that exists in Debian like
> gcc-4.9 or automake1.11. However it is better to limit this to important
> packages because every time Google changes the version, the package name
> must be updated too. Otherwise the package name wouldn't reflect the
> content.
> 
> Please also keep in mind that every package name change has to go
> through Debian's NEW queue which puts additional burden on the FTP team
> and sometimes it simply takes a lot of time. Now imagine we have to do
> that for multiple packages.
> 
> At the moment I don't know enough about the underlying rationale for
> those packages and why we need to provide sources files in binary
> packages. I think it would be a good idea to summarize all these
> thoughts somewhere. For instance why do we need to ship *.java files and
> why can't we just compile them to class files?

About android-platform-libcore-source-6.0.1,  seems like we'll have to
combine multiple upstream git repos into a single debian source package
if android.jar needs to be built from multiple git repos at the same
time.  I think a source package can have multiple source tarballs, so
the source tarballs could still be directly tied to the git repos.

Another approach that's a bit hacky is packaging the bits of android.jar
separately from each git repo, then make a post-install script that
compiles android.jar from them.  Markus might kill me for making that
suggestion ;)

.hc