ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

On Thu, May 1, 2014 at 5:16 PM, Ted Gould <ted@xxxxxxxxxx> wrote:

>  On Thu, 2014-05-01 at 17:01 -0400, Chris Wayne wrote:
>
> We currently have some upstart jobs that set certain env variables, like
> the dconf db/profile to use the customized dconf keys.
>
>
> It seems like this should be the default, not something in the custom
> tarball. Is there any reason we'd not want to enable the custom DConf DB if
> it exists?
>

None that I know of, I'd just prefer to have all customization bits in the
tarball, instead of having some in the rootfs, and then others in the
tarball.

>
>
>  Also a carrier may want to enable/disable certain services (think 4g
> tethering) for example,
>
>
> This seems like it'd be better handled with a DConf key for that service.
> It's also allow it to be more dynamic.
>
>
>  or maybe a different provider for ubuntu-location-service.
>
>
> Here we should probably provide a way to add these via a click package.
>

Right, the actual installation of it would be in a click package, but I'd
imagine which service to use would be in the form of an upstart override.

>
> All in all, I'm not against Upstart having the feature, but it's a big
> scary stick and basically an unsupportable interface. If we change the
> signals or the job names in an image update, suddenly that update breaks
> that customization tarball and device, potentially in a hard to fix manner.
>
>
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?

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

Ted
>