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>
>> <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.
