ubuntu-appstore-developers team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxx>]

On Thu, Jul 3, 2014 at 8:14 PM, Martin Albisetti <
martin.albisetti@xxxxxxxxxxxxx> wrote:

> On Thu, Jul 3, 2014 at 10:24 AM, Loïc Minier <loic.minier@xxxxxxxxxx>
> wrote:
> > Well, that should all be in the chroot; that is, if you're creating Click
> > packages against the latest frameworks from a LTS host, you need an
> > up-to-date Click, probably debootstrap, and then an up-to-date click
> chroot
> > of utopic. Click is fairly stable and low on dependencies though, so I
> dont
> > expect much more has to be backported. Backports / PPA are for the rare
> case
> > where we're updating packages in some touch-stable series (stable in the
> > sense of the system-image channel).
>
> That sounds a bit heavy-weight for the server. At least for now. OTOH,
> you already mentioned that it's the ideal scenario and not a
> requirement for today  :)
>

It shouldn't be heavy-weight; it's basically running the commands we're
running under a chroot; the tool to create the chroots and run commands in
them are already there. Is it the usage of root that worries you, or the
load to debootstrap/size of the chroots?


> How do you envision this happens?
> Each time there's a new framework, there's a script run that creates a
> new chroot for that combination?
>

I'd think a daily cron or such updates the chroot on the server; this pulls
the latest framework definitions and corresponding deps.


> Separately, I don't think these chroots are aware of what's
> deprecated, what's no longer supported, etc. Are they?

We need to have the full history at hand to give developers sensible errors.


That's a good point; so far, this information was only in the store and in
the click reviewers tools; perhaps it ought to be preserved within the
frameworks themselves, but that wont help much to discover which chroot to
use for which framework. I wonder whether it would be ok to store this in
click itself. Click was trying hard not to hardcode any specific
relationships to frameworks, but I'm not sure where else to keep the
central map of chroots/series -> frameworks. Perhaps a separate package is
needed to keep this data, just like debootstrap or distro-info.

Cheers,
-- 
Loïc