← Back to team overview

ubuntu-phone team mailing list archive

Re: Customized Upstart Jobs/Overrides

 

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 )?

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?

/t












Follow ups

References