[pkg-fso-maint] fso-usaged config-change

[Heiko Stübner]

Am Donnerstag 22 Oktober 2009 schrieb Nikita V. Youshchenko:
> > Am Donnerstag 22 Oktober 2009 schrieb Nikita V. Youshchenko:
> > > > I updated the openmoko-files-config git accordingly.
> > > Any plans to upload newer configuration package(s)?
> > It seems there are also other unreleased changes by Joachim and Timo
> > Jyrinki related to power button handling and volume-settings - are they
> > ok to release?
> I think that currently we may change whatever we want after simplest "works
> for me" test. FSO packages are not yet at that stage when we need to think
> how "not to break existing setups" - those are almost permanently broken
> anyway :).
ok

> > Second question would be: should we (fso-config-gta*) depend on
> > fso-usaged and enable the config options for it by default?
> 
> I think that default config files should assume fso-usaged.
> However, config package should not depend on fso-usaged, to avoid circular
> dependency.
hmm ... I don't see the circular dependency but I may overlook something:
  fso-frameworkd recommends fso-config and fso-usaged
but
  fso-config-* would depend on fso-usaged as it is enabled in the config 
provided by it
  fso-usaged does not depend on either as it's a leaf package

> If you have some time to kill, you may write a script that enables/disables
> frameworkd services, include it info config package, and then use it in
> fso-usaged preinst/postinst :).
A system of split config files for frameworkd was proposed in the past I think.
But sadly with university and work I'm in no position to implement such a 
thing at the moment. 

> Btw, what config package is for? Why not include configs in frameworkd
> package? Is that for gta01/gta02 differences? What are these differences?
> Can't those be handled somehow within frameworkd package?
I think the rationale was to keep frameworkd as generic and device agnostic as 
possible. As a result frameworkd only included a config-package (fso-config-
general) with all services disabled and device-specific packages would provide 
an actual working configuration.

> One more thing - about libphone-utils.
> 
> Previously we talked that libphone-utils configuration file can't be
> included in library package, because it is against the Policy.
> 
> I just thought that my previous suggesion - to couple libphone-utils
> configuration with frameworkd configuration - is somewhat silly. Both
> frameworkd and libphone-utils may be of use without other one, so mixing
> those at packaging level looks wrong.
> Instead I looked at /etc/nsswitch.conf file.
> It is a configuration file of a library (glibc) - so situation looiks
> similar.
> And that file is not provided by whatever package. Instead, it is created
> by postinst.
> 
> We may (and probably should) do exactly same thing with libphone-utils
> config. Generate it in postinst if it does not exist yet, and remove it on
> libphone-utils package purge.
I don't think I can comment on this, as I didn't follow the discussion really 
closely - wasn't this Sebastians playground?

While reading your comments I thought something like the apache modulehandling 
would do the trick, i.e. packages install their snippets in 
/etc/{something}/modules-available which are then enabled or disabled by the 
packages using symlinks to /modules-enabled. For example fso-config-XXX 
installs ousaged.mod and activates it. When fso-usaged is installed it install 
fsousaged.mod, activates it while deactivating ousaged.mod.

Heiko