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

Wed Jul 20 17:22:04 UTC 2016

On Wed, Jul 20, 2016 at 10:30 PM, Mouaad Aallam <mouaad at aallam.com> wrote:
> Hi,
>
>> [1]:
>> https://github.com/Aallam/debian_google-android-platform-installers/commit/00d725ba57670d3c2730f8c5b17e5e6384118f19#commitcomment-18311035
>
>
> For this one, my first intuition was indeed to make one single `templates`
> file for them all, but that was not possible because when I create a single
> templates file, only the first package uses it, the other package does not
> use it and the error message is something like: "templates file is not
> found", so was forced to make a corresponding <package>.templates to every
> <package>.config
I see.
>
>>
>>
>> [2]:
>> https://github.com/Aallam/debian_google-android-platform-installers/commit/00d725ba57670d3c2730f8c5b17e5e6384118f19#commitcomment-18311048
>
>
> Here there is two risks/problems why I've done it like this:
> 1-  the platform zip contains always a folder with a different name than the
> wanted one (for example for platform-24 zip have file android-N and but in
> the install folder it should be android-24, for platform-23 it's
> android-5.1.1.. install folder should be android-23 and so on), so if I
> unzip directly there, it must be `mv` anyway.
What I meant here was use unzip -d android-23, and so on.
The d options let you specify a directory to move to.
> 2- 2nd this is: if it must be mv anyway, why not do it in the cache folder
> just in case, for example, the unzipping is interrupted (ctrl+c), or any
> other issue, with unzipping in the cache, and mv only when the unzipping is
> complete, I make sure to have a folder with all correct files.
No need to mv if you unzip it to the right dir in the first place.
>
>
>> What I thought was the script could be for us developers
>
>
> I think this may be more reasonable and easy to do, but we may have some
> small issues (for example, platform-24_r01.zip after unzipping the folder
> name is android-N, how can you get this information ?  (not available in the
> XML, and available for versions <= 23)
That should be fine, we can just directly unzip to the correct dir
(which is android-<number> for all, right?)
AFAIK L/M/N codenames are used before the actual release of that
particular android version.
>
>
> Mouaad Aallam
>
> On Wed, Jul 20, 2016 at 5:44 PM, Chirayu Desai <chirayudesai1 at gmail.com>
> wrote:
>>
>> 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
>>
>> _______________________________________________
>> 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