On Thu, Jul 3, 2014 at 8:14 PM, Martin Albisetti < [email protected]> wrote:
> On Thu, Jul 3, 2014 at 10:24 AM, Loïc Minier <[email protected]> > 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
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
