[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
Chirayu Desai
chirayudesai1 at gmail.com
Wed Jul 27 17:04:53 UTC 2016
Hi,
I agree with you that we should make it build only the current
platform (23 as of now).
I have started to work on the new source package which does that.
I have a preliminary version ready at [1]. It includes 4 upstream
repositories - frameworks/base, frameworks/opt/telephony,
frameworks/opt/net/voip and libcore. 2 of them already exist in
debian, frameworks/base and libcore. I moved everything from those
repos (debian/) to this new package, and almost have it building (need
to do some work to get the java and non-java parts to co-exist).
[1]: https://gitlab.com/cde/debian_android-tools_android-framework-23
However, seamlik pointed out something which I hadn't thought of.
Moving the frameworks/base packages such as aapt to this new repo will
make us need to request a transition every time a new release occurs,
and it would have to go through the NEW queue.
So what was suggested is to use the new package to only build
android.jar (i.e. a component which we'll need multiple versions of),
and keep the latest tools in android-platform-frameworks-base.
The options I have in mind are:
New source package android-framework-23 with the 4 upstream tarballs
1a. It replaces android-frameworks-base. When Android N source code is
available, we would have a android-framework-24. The packages like
aapt would have to transition again.
1b. It co-exists with android-frameworks-base. After N, we would have
android-framework-24, and android-platform-frameworks-base would also
get updated to N. So we would have the latest tools such as aapt, and
also android.jar
Also, what about the java packages libcore provides? Does it need to
be folded in, or can those packages always stay at the latest too?
Either way, the plan would be to get the current (23) version working,
and by the time we have it all working we'll probably have the next
release to work on. The old releases (22 and below) would be fetched
from Google via the contrib packages.
I've also tried to make the source package (and the files in debian/)
as generic as possible, which should be good longterm. The name can
also be changed easily before upload to debian if needed. there's only
the minimal occurrences in d/changelog and d/control. I made
everything else use variables. More upstream repos can also be added
easily, I made that dynamic as well, so to add frameworks/foo/bar, we
would only need to add that word to a variable in d/rules, and then
import the upstream source.
Regards,
Chirayu Desai
On Thu, Jul 21, 2016 at 7:30 PM, Hans-Christoph Steiner <hans at at.or.at> wrote:
>
> I'm thinking we should call the new source package "android-platform"
> and make it build only the current platform (e.g. 23) from source. The
> rest we can get from Google or download old Debian packages. Later, we
> can always revisit that and build more platforms from source.
>
> "android-platform" should include multiple upstream source tarballs,
> hopefully unmodified. Ideally this new source package would include
> enough source tarbals that there are no longer circular dependencies,
> but that's not a hard, fast rule since we now know how to manage them.
> Then the android-platform-frameworks-base source package can be removed.
>
> My main concerns are:
> a) upload process should be easy
> b) we should use upstream tarballs as much as possible
>
> Beyond that, I think what we can do is pretty flexible. I wouldn't
> worry about disk space, its not that big.
>
> .hc
>
>
> Chirayu Desai:
>> Hi,
>>
>> On Tue, Jul 19, 2016 at 8:48 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>> Hi Chirayu,
>>>
>>> I still can't accept all platforms reside in one source package, as
>>> platforms are increasing indefinitely until Android is dead (not
>>> likely...), resulting that the source package keeps growing in size
>>> indefinitely, unless we will remove some of the very old platforms
>>> from the package as the time goes by. Also, this package will take
>>> more and more time to build.
>> I totally agree with that, I never said that we should have a
>> 'android-platform' package containing all the platforms. It would get
>> big soon, and would be hard to do that from the source code.
>> Just like the 'android' tool bundled with the SDK, and like the
>> google-android-platform-<n>-installer packages being worked on, I
>> would imagine we would end up with packages like android-platform-<n>,
>> with n being 23, 24, etc.
>>>
>>> If we make every platform a source package, we can still only package
>>> platforms that have more market share. Even though once some platforms
>>> become very old, we don't have to remove them, we can just keep them
>>> as is.
>> Right. But we do end up with ~7-8 source repos for now at least, and
>> more as newer Android versions come. We could do versions (15?)
>> 16,17,18,19,21,22,23 (and 24 when we have source code in a month or
>> so) - Source is what app developers would check, [1]
>>
>> [1]: https://developer.android.com/about/dashboards/index.html
>>>
>>> Right now Android Platform 23 is the latest API and we are only
>>> several steps away from a complete "android.jar".
>> Yep. 24 is available but source code isn't yet, so I guess we can get
>> everything done for 23.
>>>
>>> Cheers,
>>> Kai-Chung Yan
>>>
>>> 2016-07-19 18:40 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>>> Hi,
>>>>
>>>> On Tue, Jul 19, 2016 at 2:41 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Sorry for the late reply, I am finally able to use a Debian laptop...
>>>>>
>>>>> So, we now have 2 options for the road beyond:
>>>>>
>>>>> 1. Integrate 3 other repos into src:android-platform-frameworks-base
>>>> We already build things from the above, so it would be good. Name
>>>> would be confusing though.
>>>>> 2. New src:android-platform-23 or src:android-platform-framework-23
>>>>> for a combination of 4 repos
>>>> This would be less confusing, and I guess we'll also move things like
>>>> aapt and framework-res to the new repo.
>>>>>
>>>>> If we do not need to care about disk spaces for Debian's servers,
>>>>> option #2 is also preferred by me. Because if we are making a new
>>>>> source package for option #2, this package will have duplicated codes
>>>>> in src:android-platform-libcore and
>>>>> src:android-platform-framework-base. What should we do to this 2
>>>>> existing packages? We have several options:
>>>>>
>>>>> A) Remove src:android-platform-libcore as all of its binary packages
>>>>> can also be built in src:android-platform-framework-23
>>>> +1
>>>>> B) Remove those large-sized resource files, which are used to build
>>>>> frameworks-res.apk, from src:android-platform-frameworks-base. This
>>>>> source package used to exclude all those resource files in order to
>>>>> keep fit.
>>>> They aren't that large.
>>>> cdesai at sid: ~/android-tools/android-platform-frameworks-base
>>>> ((e9bbe9a9d6...)) $ du -sh core/res/
>>>> 56M core/res/
>>>>> C) Remain the 2 existing packages as is and only include necessary
>>>>> file in src:android-platform-framework-23
>>>> That'll lead to some duplication, but also make the existing
>>>> frameworks-base smaller.
>>>>>
>>>>> In option #C, packages like libandroid-json-java and
>>>>> android-framework-res are still built from where they are now. I am
>>>>> not sure but if the upstream "framework-res.apk" only contains
>>>>> resource files but not any Java classes, option #C seems nice.
>>>> It does not contain any java classes at all.
>>>> core/res is what is included in it, nothing more.
>>>> That's why we're able to build it with a one liner with aapt.
>>>>>
>>>>> Cheers,
>>>>> Kai-Chung Yan
>>>>
>>>> There's one more concern here. This is just for 23. What about the
>>>> older releases? Many are still quite popular. And the newer release
>>>> (7.0), which'll come sometime around August/September, will also need
>>>> quite some work - and a lot of repos too, if we make
>>>> src:android-platform-<n>.
>>>>>
>>>>> 2016-07-02 13:08 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jun 30, 2016 at 4:48 PM 殷啟聰 <seamlikok at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Including libcore, frameworks/opt/telephony & frameworks/opt/net/voip into
>>>>>>> src:android-platform-frameworks-base does make sense because:
>>>>>>>
>>>>>>> * This 3 repos are necessary to build the "android.jar", so it makes sense
>>>>>>> to
>>>>>>> put them together.
>>>>>>
>>>>>> Agreed. It would be best to have those 3 upstream repos in one debian source
>>>>>> package.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * "android.jar" is the core of an "Android Platforms", hence it makes
>>>>>>> sense to remain the package name as "android-platform-frameworks-base".
>>>>>>
>>>>>> Still don't agree with this, as this source package already exists and name
>>>>>> android-platform-foo is used for upstream repo platform/foo. Minor nit in
>>>>>> the grand scheme of this though.
>>>>>>>
>>>>>>>
>>>>>>> Using "sources.zip" may not be a good idea because:
>>>>>>>
>>>>>>> * "sources.zip" and "platforms.zip" are non-free just like the official
>>>>>>> SDK
>>>>>>> bundle.
>>>>>>
>>>>>> I think the idea here was to create our very own sources.zip (I think that's
>>>>>> what I remember from the chat with hc on IRC a few days ago)
>>>>>>>
>>>>>>> * "sources.zip" still lacks some classes in "android.jar". (For example
>>>>>>> the
>>>>>>> classes in "junit/" directory
>>>>>>
>>>>>> Are those classes included included under a folder with their package name
>>>>>> perhaps?
>>>>>> I remember getting confused by that for some other class.
>>>>>>>
>>>>>>>
>>>>>>> Although the Java sources inside the "sources.zip" is open source, the
>>>>>>> tarball
>>>>>>> itself is not. I do not know if that violates Debian's policy. If we are
>>>>>>> creating source packages depending on this tarball, the package might
>>>>>>> remain in
>>>>>>> "non-free" category.
>>>>>>>
>>>>>>> As we all have observed the structure of the "platforms/" directory, we
>>>>>>> know
>>>>>>> that the "Android Platforms" consists of plenty of files originate from
>>>>>>> various
>>>>>>> upstream repos, which makes it very complicated to reproduce the entire
>>>>>>> "Android
>>>>>>> Platforms" from source. How about we make a source package
>>>>>>> src:google-android-platforms-installer consists of downloader packages of
>>>>>>> all
>>>>>>> "Android Platforms" directly from Google?
>>>>>>
>>>>>> I agree with this, trying to build the android platforms would not be a good
>>>>>> idea.
>>>>>> What we could do is have the open source installer / manager (android
>>>>>> command) and then perhaps have those downloader packages containing the
>>>>>> upstream repository info (i.e. just the xml)
>>>>>> Also, since those platforms wouldn't be oss they would probably go to
>>>>>> non-free. I'm not exactly sure about this.
>>>>>> However, I remember seeing an alternative (hc linked it a few days ago),
>>>>>> somebody had recompiled all the platforms from the aosp sources - we could
>>>>>> create a repository xml from that and put it in contrib.
>>>>>>
>>>>>> hc another email about this with some ideas.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Kai-Chung Yan
>>>>>>>
>>>>>>> 2016-06-17 14:47 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>>>>>>> We could run doclava on those files, which is what would have to be
>>>>>>>> done anyways.
>>>>>>>> So,
>>>>>>>> frameworks/base = full sources.
>>>>>>>> sources.zip = full public API sources, no hidden methods or classes
>>>>>>>> android.jar = stubs compiled using doclava from either of the above,
>>>>>>>> doclava is what produces the file list for sources.zip in the first
>>>>>>>> place.
>>>>>>>>
>>>>>>>> sources.zip and android.jar should have matching classes (apart from
>>>>>>>> maybe uiautomator, not sure) - the content of each class would differ
>>>>>>>> (stubs vs code), but there wouldn't be any class which is in
>>>>>>>> android.jar and not in sources.zip
>>>>>>>>
>>>>>>>> On Fri, Jun 17, 2016 at 12:41 AM, Hans-Christoph Steiner <hans at at.or.at>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think I just found the fatal flaw in the sources-23-r01.zip approach:
>>>>>>>>> sources-23-r01.zip contains the full .java source files, file
>>>>>>>>> android.jar includes only the stub versions. Is there a tool that we
>>>>>>>>> can easily convert those sources to the stubbed versions? If not, then
>>>>>>>>> we should go with the plan that seamlik outlined.
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>> Hans-Christoph Steiner:
>>>>>>>>>>
>>>>>>>>>> Chirayu and I are probing around this approach. I think it makes
>>>>>>>>>> sense
>>>>>>>>>> to make a custom source tarball for the platforms based on
>>>>>>>>>> sources-23_r01.zip, platform-23_r03.zip, then the remaining bits from
>>>>>>>>>> android-platform-frameworks-base.
>>>>>>>>>>
>>>>>>>>>> Then we can keep the current android-platform-frameworks-base as it
>>>>>>>>>> is.
>>>>>>>>>> For things that might need security updates like aapt, etc., they
>>>>>>>>>> should use the one-package-per-git-repo model so its easy to do
>>>>>>>>>> security
>>>>>>>>>> updates. The android-platform-23 package does not really have
>>>>>>>>>> executable code, instead just API files for cross-compiling.
>>>>>>>>>>
>>>>>>>>>> .hc
>>>>>>>>>>
>>>>>>>>>> Hans-Christoph Steiner:
>>>>>>>>>>>
>>>>>>>>>>> Is this only about building the 'platform' and android.jar? How
>>>>>>>>>>> about
>>>>>>>>>>> making a custom source package from the two upstream tarballs:
>>>>>>>>>>>
>>>>>>>>>>> https://dl.google.com/android/repository/platform-23_r03.zip
>>>>>>>>>>> https://dl.google.com/android/repository/sources-23_r01.zip
>>>>>>>>>>>
>>>>>>>>>>> We could make a little script that downloads those two and repacks
>>>>>>>>>>> into
>>>>>>>>>>> a DFSG-free tarball with just .java and res XML. Would that cover
>>>>>>>>>>> everything needed?
>>>>>>>>>>>
>>>>>>>>>>> .hc
>>>>>>>>>>>
>>>>>>>>>>> 殷啟聰:
>>>>>>>>>>>> Hi Chirayu,
>>>>>>>>>>>>
>>>>>>>>>>>> IMO it is fine to reuse this existing
>>>>>>>>>>>> src:android-platform-frameworks-base. And we will probably need to
>>>>>>>>>>>> file an removal of src:android-platform-libcore since everything is
>>>>>>>>>>>> built from src:android-platform-frameworks-base.
>>>>>>>>>>>>
>>>>>>>>>>>> It is indeed highly likely that we will need to prepare another
>>>>>>>>>>>> merged
>>>>>>>>>>>> source package when we are doing NDK, but I think it is fine to
>>>>>>>>>>>> avoid
>>>>>>>>>>>> the merging as long as every single artifacts (e.g. .so, .jar) can
>>>>>>>>>>>> be
>>>>>>>>>>>> built from an independent repo of AOSP.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Kai-Chung Yan
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Kai-Chung Yan
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-06-15 17:37 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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>
>>> */
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
More information about the Android-tools-devel
mailing list