On Thu, May 1, 2014 at 5:16 PM, Ted Gould <[email protected]> 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 >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
