ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

On Thu, May 1, 2014 at 9:16 PM, Ted Gould <ted@xxxxxxxxxx> 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> 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.
>
>
> I'd agree that all the customization should be in the tarball, but the
> parts that detect the customization and use it should be in the rootfs. The
> distinction I'm making here is that the DConf database should be in the
> tarball, but detecting and deciding to use it should be on the rootfs.
>
>
>   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.
>
>
> No. Click packages can not and should not install files into the
> filesystem, they are self contained. It is possible that they would provide
> declarative hook that could be implemented by an Upstart job, but the click
> package itself should be in no way dependent on or use Upstart directly.
>

I didn't mean to imply that such an upstart job would be in the click
package itself.  This may not have been the best example to give on my part
anyway, as that could probably be set by a DConf key or something instead.


>
>  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?
>
>
> 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.
>
> No, but in our base customization image (savilerow) we have every
supported customization, exactly so that we can test the customization API,
and can ensure that all types of customizations work.  Again, the
location-service was a quick example that I made up (and is clearly not the
greatest example to have used!).  I still don't quite understand the claim
that having custom upstart jobs makes it any less stable than upstart jobs
that live 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
>
>
> 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.
>

We expect the first phones that we ship to have Upstart, therefore it's
going to be around at least long enough that we will need this.

>
>
> Ted
>