ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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 <ted@xxxxxxxxxx
> >> <mailto:ted@xxxxxxxxxx>> 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

Attachment: signature.asc
Description: This is a digitally signed message part