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

Wed Jul 20 17:00:58 UTC 2016

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

>
> [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.
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.

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)

*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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160720/4553f961/attachment-0001.html>