[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
Chirayu Desai
chirayudesai1 at gmail.com
Wed Jun 15 09:37:25 UTC 2016
Hi,
I get what you mean, which is why I suggested the src:android package.
The name can be something else, but I would say it could be something
other than android-platform-frameworks-base too because that would be
confusing as well.
So src:name-of-new-package-for-android-jar
tree:
frameworks
base
opt
net
voip
telephony
libcore
debian
which would be used to build the android.jar, having all the android
sources needed in one debian source package would make it easier.
Question is, what about the existing frameworks-base package, and the
other packages it builds (aapt, etc)
Also, it might be worth to think if we would need to do this kind of
thing again in the future, for something else like the NDK or emulator
images (just some random examples, as the emulator images would need a
full android build which would be really complex)
Cheers,
Chirayu Desai
On Wed, Jun 15, 2016 at 3:01 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
> Hi Chirayu,
>
> We can refer to the way how src:android-platform-system generate the
> merged upstream tarball. And I don't think we need git submodule or
> repo, because Git is only used to manage the history of our debian/
> files, not the upstream files. We don't really need so much
> complicated mechanism...
>
> Cheers,
> Kai-Chung Yan
>
> 2016-06-15 17:22 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>> Hi,
>>
>> On Wed, Jun 15, 2016 at 2:43 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>> Hi,
>>>
>>> The name of "src:android" is too general. Since this repo contains
>>> mostly files of android-platform-frameworks-base, we can simply reuse
>>> this source package. Actually there was an src:sndroid-platform-system
>>> [1] which consisted of android-platform-system-core and
>>> android-platform-system-extras, but we later use staged builds to
>>> resolve the circular dependency between them and we split them up.
>>> src:android-platform-frameworks-compile [2] is also a combination of
>>> multiple upstream sources, but I am also thinking about splitting them
>>> up.
>> Yes, I agree "src:android" is too general. However I suggested that
>> because you said you wanted to maintain the upstream structure, and I
>> would think that it would make sense.
>>
>> Or did you mean something else?
>>
>> It seems that if there was a way to properly replicate the upstream
>> structure properly, i.e. one git repo per upstream repo, one source
>> tarball, etc., and then do something combining all of those, it might
>> be best. If possible, of course.
>>
>>>
>>> Cheers,
>>> Kai-Chung Yan
>>>
>>> [1]: https://anonscm.debian.org/cgit/android-tools/android-platform-system.git
>>> [2]: https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-compile.git
>>>
>>> 2016-06-14 22:24 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>>> Hi,
>>>>
>>>> On Tue, Jun 14, 2016 at 6:54 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>>>> Hi Markus and Hans,
>>>>>
>>>>> The reason of providing Java source files in android-platform-libcore
>>>>> is because we use Doclava to analyze all Java source of the Android
>>>>> platform framework and generate some API stubs which are Java sources
>>>>> having only the definitions but not the implementations, much like a
>>>>> header file in C/C++. And "android.jar" is built using these API
>>>>> stubs. All compiled classes are bundled into a single "android.jar",
>>>>> so we are not building any separated Java libraries.
>>>>>
>>>>> I successfully built "android.jar" in the android-jar-old branch [1]
>>>>> and after I compare this "android.jar" to the upstream one I found
>>>>> that it is not enough. We need 2 more repos:
>>>>>
>>>>> * https://android.googlesource.com/platform/frameworks/opt/telephony
>>>>> * https://android.googlesource.com/platform/frameworks/opt/net/voip
>>>>>
>>>>> I find it unacceptable if we are also building another 2 binary
>>>>> packages containing Java source files and with version string in the
>>>>> package names. So it would be better if we combine
>>>>> android-platform-libcore and this 2 repos into one single
>>>>> src:android-platform-frameworks-base.
>>>> Or it could be a new single src:android, preserving the upstream
>>>> directory structure.
>>>> i.e.
>>>> android
>>>> frameworks
>>>> base
>>>> opt
>>>> net
>>>> voip
>>>> telephony
>>>> libcore
>>>>
>>>> and so on.
>>>>
>>>> However, it might get too big.
>>>> Also, existing packages, mainly from
>>>> src:android-platform-frameworks-base would have to be migrated.
>>>>
>>>> Is there any other saner way?
>>>> Could we perhaps use git submodules (or upstream's 'repo' tool) in some way?
>>>>>
>>>>> I don't know if there are any conventional or simple way of making a
>>>>> source package tarball from multiple upstream tarball. I only know
>>>>> that the latest uscan (version 4 watch file) supports creating
>>>>> tarballs from multiple upstream tarballs, but I don't know if
>>>>> mk-origtargz supports it or there are other ways.
>>>>>
>>>>> Cheers,
>>>>> Kai-Chung Yan
>>>>>
>>>>> [1]: https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-base.git/?h=android-jar-old
>>>>>
>>>>> 2016-06-10 18:53 GMT+08:00 Markus Koschany <apo at debian.org>:
>>>>>> On 08.06.2016 20:43, Hans-Christoph Steiner wrote:
>>>>>> [...]
>>>>>>> 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.
>>>>>>
>>>>>> Sure, you can combine multiple upstream repos into one Debian repo as
>>>>>> well. It is just a matter of documentation.
>>>>>>
>>>>>>> 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 ;)
>>>>>>
>>>>>> I guess I need to see the whole packaging for android.jar first before I
>>>>>> ask Igor to do something terrible. ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Android-tools-devel mailing list
>>>>>> Android-tools-devel at lists.alioth.debian.org
>>>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> /*
>>>>> * 殷啟聰 | Kai-Chung Yan
>>>>> * 一生只向真理與妻子低頭
>>>>> * Undergraduate student in National Taichung University of Education
>>>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>>>> * Blog: <http://seamlik.logdown.com>
>>>>> */
>>>>>
>>>>> _______________________________________________
>>>>> Android-tools-devel mailing list
>>>>> Android-tools-devel at lists.alioth.debian.org
>>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>>
>>>
>>>
>>> --
>>> /*
>>> * 殷啟聰 | Kai-Chung Yan
>>> * 一生只向真理與妻子低頭
>>> * Undergraduate student in National Taichung University of Education
>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>> * Blog: <http://seamlik.logdown.com>
>>> */
>
>
>
> --
> /*
> * 殷啟聰 | Kai-Chung Yan
> * 一生只向真理與妻子低頭
> * Undergraduate student in National Taichung University of Education
> * LinkedIn: <https://linkedin.com/in/seamlik>
> * Blog: <http://seamlik.logdown.com>
> */
More information about the Android-tools-devel
mailing list