On Fri, 2014-05-02 at 11:36 -0400, Tony Espy wrote: > On 05/01/2014 09:16 PM, Ted Gould wrote: > > On Thu, 2014-05-01 at 18:28 -0400, Chris Wayne wrote: > >> On Thu, May 1, 2014 at 5:16 PM, Ted Gould <t...@ubuntu.com > >> <mailto:t...@ubuntu.com>> wrote: > > <snip> > > >> That's why we have the -customized images tested by CI daily :) Any > >> update to the image that breaks customization would be found (and > >> fixed) before an image would be promoted. I don't see how having > >> custom upstart jobs makes it any more likely to fail than having > >> upstart jobs in the rootfs? > > > > Heh, we're not going to have every customization for every device on > > every carrier. It'd be nice, but we probably won't even have an > > environment that could test things like customized location providers > > (likely to require specific cell towers for instance). What's important > > is that we keep the things that can be customized as a stable API, if we > > can't guarantee that, we shouldn't allow it be customized. > > > >> All in all, we think this is something that a carrier/oem would > >> want/need to customize, and it'd be much easier to add now, than to > >> scramble later > > > > So the more we talk about this, the more I think it's a bad idea. I'm > > now of the opinion that we shouldn't provide this to customization > > tarballs. If nothing else, because we don't expect to support Upstart as > > long as we expect the customization tarballs to work. > > So are you implying that systemd doesn't have a similar concept ( ie. > overriding default jobs )?
No, I'm saying if you provide an override for an Upstart job it won't work on a Systemd unit. So to create a customization tarball you'd have to override both. (one of which isn't well defined right now) > One example that was brought up recently was a carrier that wants to > ship a *replacement* apns-conf.xml file ( which currently lives in > /system/etc ). One way to accomplish this is to set an environment > variable called OFONO_APNDB_PATH which the ofono provisioning plugin > queries before using the default path. Is there another way to expose > custom environment variables to system upstart jobs besides using an > override? I'd say that the Upstart job for ofono that we ship should check for /custom/apns-conf.xml and use that if it exists. We should support as an interface shipping the actual override, not changing the way that oFono works. Let's say we have a situation where we have an oFono job today. And for what ever reason we decide that we have an ofono-helper job that needs to run first. So if the original job was "start on started networking" we'd change it to "start on started ofono-helper" and then the ofono-helper job would be "start on started networking". But if the ofono job was replaced in a customization tarball it would still have the "start on started networking" so, on that particular configuration, they'd run at the same time and have a race condition. Now that situation is a bit contrived because the ofono-helper could be "start on starting ofono", but I hope it illustrates some of the issues. Ted
signature.asc
Description: This is a digitally signed message part
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
