[Android-tools-devel] Fwd: google-android-platform-* packages WAS: android-platform-libcore/6.0.1+r16-1

Wed Jul 20 16:44:03 UTC 2016

Hi,

On Wed, Jul 20, 2016 at 7:43 PM, Mouaad Aallam <mouaad at aallam.com> wrote:
> Hello
>
>> I left a few comments on the commit [1].
>> This could be less hardcoded, and a bit more generic.
>> You could also create and put some templates like
>> google-android-platform-N-installer.postinst, with some variables
>> inside the file. So to add a new version we could just run sed on
>> those and replace the values, basically make it easier to script this
>
>
> Yes, thank you, I've checked your comments :)
> I've taken them into consideration and I've pushed to the git to fix some
> things.[1]
Thanks, it looks like most of them have been addressed.

What do you think about [1], and [2]?

[1]: https://github.com/Aallam/debian_google-android-platform-installers/commit/00d725ba57670d3c2730f8c5b17e5e6384118f19#commitcomment-18311035
[2]: https://github.com/Aallam/debian_google-android-platform-installers/commit/00d725ba57670d3c2730f8c5b17e5e6384118f19#commitcomment-18311048

There's also the case of trying to use the substvars for the
description as well, to avoid copy pasting that big glob of test
everytime.
> And yes, the finality is to make a generic package as much as possible, the
> package was just a scratch ;)
>
>> I could make the script, given I'll be already making more for the
>> upstream updates / uploads.
>>
>> Or should I let him get the script done as well?
>
>
> I already had the idea of making a parsing script but didn't know if it is
> "acceptable" to do so for debian packages because the package will be
> dependent on google's XML file, but now that's I see that it is acceptable I
> can do it (for the package I'm working on at least).
What I thought was the script could be for us developers, put in a
scripts repo (I already have one locally for the upstream update
script), and we would run it to generate most of the google-* source
packages as needed. Which is why I asked you to add templates. It
would make life easier than trying to add new versions manually (which
would be error prone as well), and we can do any final changes /
commit the update manually.

I didn't think about putting the script itself on the source package
because that might make it more complex, and would also make the
script more complex - the above would be a simple xml parser that
would spit out a few values.
I could do it in python, as I haven't ever used or learnt perl. What
do you think?

And I would say that it should be generic, just take the xml and print
out a list of everything we care about (i.e. platforms greater than a
set version, matching sdk docs, and so on).
>
> [1]: https://github.com/Aallam/debian_google-android-platform-installers
>
> Mouaad Aallam
>
> On Wed, Jul 20, 2016 at 7:54 AM, Chirayu Desai <chirayudesai1 at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I left a few comments on the commit [1].
>> This could be less hardcoded, and a bit more generic.
>> You could also create and put some templates like
>> google-android-platform-N-installer.postinst, with some variables
>> inside the file. So to add a new version we could just run sed on
>> those and replace the values, basically make it easier to script this.
>>
>> [1]:
>> https://github.com/Aallam/debian_google-android-platform-installers/commit/00d725ba57670d3c2730f8c5b17e5e6384118f19
>>
>> On Wed, Jul 20, 2016 at 3:34 AM, Mouaad Aallam <mouaad at aallam.com> wrote:
>> > Here is a start for the package android-google-platform-installers[1]
>> > which
>> > generate installers for platform 24, 23 and 22 (I think it's easy to add
>> > older platforms). I will try to improve this even more following the
>> > suggestions and discussions we had.
>> >
>> > [1]: https://github.com/Aallam/debian_google-android-platform-installers
>> >
>> > Mouaad Aallam
>> >
>> > On Tue, Jul 19, 2016 at 9:59 PM, Hans-Christoph Steiner <hans at at.or.at>
>> > wrote:
>> >>
>> >>
>> >> I think making the source package use a python or perl script to parse
>> >> the Google repo XML makes sense.  Then we can just build the source
>> >> package, and it would generate all of the latest binary packages
>> >> needed.
>> I could make the script, given I'll be already making more for the
>> upstream updates / uploads.
>> >>
>> >> I'll let Mouadd take the lead on this one since he's been doing the
>> >> work
>> >> on it so far.
>> Or should I let him get the script done as well?
>> I tried to do a bit of the generic packaging myself yesterday [2], and
>> it was useful in understanding how this kind of package works. I'll
>> let him take over though (and try to do code review), and focus on the
>> scripts.
>>
>> [2]:
>> https://gitlab.com/cde/debian_android-tools_google-android-platform-installer
>> >>
>> >> .hc
>> >>
>> >> Chirayu Desai:
>> >> > On Mon, Jul 18, 2016 at 8:40 PM, Hans-Christoph Steiner
>> >> > <hans at at.or.at>
>> >> > wrote:
>> >> >>
>> >> >> I thought about enabling `android update sdk` in the Debian
>> >> >> package's
>> >> >> version of `android`, but now I'm thinking that it would be better
>> >> >> to
>> >> >> do
>> >> >> it all with Debian packages.  I think a primary use case of the
>> >> >> Debian
>> >> >> packages will be to set up a system to build Android apps in an
>> >> >> automated way (e.g. via Chef, Puppet, Ansible, CI script, etc).
>> >> >> It'll
>> >> >> be a lot easier to do that if all of the components of the SDK can
>> >> >> be
>> >> >> directly `apt-get install`ed.  `android update sdk` is a really
>> >> >> crappy
>> >> >> package manager, and I've spent quite a bit of time fighting with it
>> >> >> when automating things like CI builds.
>> >> > I would agree here. It shouldn't take long for us to add the newer
>> >> > versions to the contrib packages (for future releases)
>> >> >>
>> >> >> I think it could make a lot of sense to have a single
>> >> >> google-android-platform-installer source package that then makes
>> >> >> multiple google-android-platform-*-installer binary pacakges for
>> >> >> each
>> >> >> platform number.  It might even make sense to have a single source
>> >> >> package for all of these installer binary packages.  The source
>> >> >> package
>> >> >> would just contain basically a template, then the build process
>> >> >> would
>> >> >> generate lots of binary packages based on replacing things in the
>> >> >> template using a list of values for all of the Google binary
>> >> >> packages
>> >> >> that we want to support, e.g.
>> >> >>
>> >> >> * docs
>> >> >> * platform-*
>> >> >> * sys_img-*
>> >> >> * build-tools-*
>> >> >
>> >> > I'm working on creating the google-android-platform-installer package
>> >> > right now.
>> >> > Experimenting reading up a bit on how to best use templates, and
>> >> > things like deb-substvars.
>> >> > A single source package for all the google binary packages could work
>> >> > too. Maybe we could even have something which parses the repository
>> >> > xml, and creates packages for things we want. Not sure if we want to
>> >> > do XML parsing though. If we do though, I have some past experience
>> >> > with python which could be helpful.
>> >> >
>> >> > I can continue with the platform-installer package, or get started
>> >> > with a generic google binary downloader, whatever suits us the best.
>> >> >
>> >> >>
>> >> >> .hc
>> >> >>
>> >> >> Chirayu Desai:
>> >> >>> Hi,
>> >> >>>
>> >> >>> This idea sounds good, and should make us able to have an android
>> >> >>> app
>> >> >>> building shortly.
>> >> >>> The "proper" SDK could come later, lots of work to do there still.
>> >> >>>
>> >> >>> There's one thing which has discussed at DebConf (informal
>> >> >>> conversation at some random place) - what we could do is use the
>> >> >>> components we have building and working currently right now, and
>> >> >>> then
>> >> >>> grab the rest from google / use contrib packages. However, it might
>> >> >>> be
>> >> >>> tricky to combine files from multiple packages, I hadn't really
>> >> >>> thought about that before. Still putting this thought here, if it
>> >> >>> turns out to be helpful.
>> >> >>>
>> >> >>> One more thing, do we want to have some sort of integration with
>> >> >>> the
>> >> >>> SDK Manager ('android' command) and debian packages? I.e., user can
>> >> >>> pick SDK platform 23 and get the platform package Mouaad created
>> >> >>> installed. If he picks emulator, he can get the emulator images
>> >> >>> downloaded directly from Google if they're not in a debian package.
>> >> >>> It
>> >> >>> would involve some code changes though, but I'm not sure exactly
>> >> >>> how
>> >> >>> much work would that be, and if it would be worth it to do that
>> >> >>> right
>> >> >>> now for the installer packages.
>> >> >>> It could still be useful later though, when we have platform
>> >> >>> packages
>> >> >>> built from source.
>> >> >>> And either way, part of this was discussed earlier as well, where
>> >> >>> the
>> >> >>> user should still be able to install his own packages / add custom
>> >> >>> stuff / install the missing packages from Google easily in a way
>> >> >>> that
>> >> >>> works with the existing debian packages.
>> >> >>>
>> >> >>> I'm just getting back to work after the DebConf trip, lots of
>> >> >>> catching
>> >> >>> up to do - I did read all of the e-mails when there, just didn't
>> >> >>> get a
>> >> >>> chance to send a proper reply until today.
>> >> >>>
>> >> >>> Regards,
>> >> >>> Chirayu Desai
>> >> >>>
>> >> >>> On Tue, Jul 12, 2016 at 11:15 PM, Mouaad Aallam <mouaad at aallam.com>
>> >> >>> wrote:
>> >> >>>> A start package for Google Android SDK Platform 24[1]
>> >> >>>>
>> >> >>>> [1]:
>> >> >>>>
>> >> >>>> https://github.com/Aallam/debian_google-android-platform-24-installer
>> >> >>>>
>> >> >>>> Mouaad Aallam
>> >> >>>>
>> >> >>>> On Mon, Jul 11, 2016 at 4:29 PM, Mouaad Aallam <mouaad at aallam.com>
>> >> >>>> wrote:
>> >> >>>>>>
>> >> >>>>>> This approach would make the packaging simpler, but I think we
>> >> >>>>>> would
>> >> >>>>>> provide a much better experience to users who are installing the
>> >> >>>>>> platforms if there was one Debian package per platform package.
>> >> >>>>>> That's
>> >> >>>>>> how the platforms are represented using the `android list sdk`
>> >> >>>>>> command
>> >> >>>>>> line tool, and the `android` GUI package installer.  That's what
>> >> >>>>>> Android
>> >> >>>>>> devs are used to.
>> >> >>>>>>
>> >> >>>>>> I think it also provides a more Debian-ish experience, I need X
>> >> >>>>>> so
>> >> >>>>>> I do
>> >> >>>>>> `apt-get install X`.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Alright then, that was just an idea I had :D, let's do it the way
>> >> >>>>> you just
>> >> >>>>> discribed then.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> 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
>> >> >>>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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