On Fri, May 2, 2014 at 4:12 PM, Tony Espy <[email protected]> wrote:
> On 05/02/2014 11:56 AM, Ted Gould wrote: > >> 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 <[email protected] <mailto: >>> [email protected]> >>> >> <mailto:[email protected]>> 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. >> > > The provisioning code in question is unique to Touch, and currently > already implements the environment variable mechanism above, primarily for > testing. It came up in a related thread started by Chris about how > carriers could implement custom APN databases. > > As for automatically checking for /custom/apns-conf.xml, that's a great > idea and it could be used to complement our existing solution. That said, > the env var mechanism will still exist. > > I just created the following bug to track this: > > https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1315509 > > [ Chris, please give the description a read, and add comments if > necessary. ] > Will do, thanks for logging it! > > For other runtime configuration settings we do try to leverage the > existing ofono upstart job ( which actually is an override as to not > conflict with the desktop version of ofono ). For instance the associated > job ril.conf uses Android properties to set environment variables that the > ofono job uses to determine which device plugin to load and how many SIMs > the device supports. > > [ Chris, does your customization scheme allow properties to be modified? ] Yes, we can currently customize properties via the use of /custom/custom.prop, although I have the feeling this should be used sparingly, as we may not always have Android bits lying around in the future :) > > > 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. >> > > Sure, I agree that it's easy to tangle things up with override jobs, > however I don't think we should prevent this type of usage as a blanket > statement. > > /tony > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
