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

[Sebastian Reichel]

On Thu, Oct 22, 2009 at 03:27:25PM +0400, Nikita V. Youshchenko wrote:
> > 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 :).

I'm more or less working on this - more information is below.

> > Second question would be: should we (fso-config-gta*) depend on
> > fso-usaged and enable the config options for it by default?

+1, I already prepared this in fso-config-gta*. I will update the
fso-usaged entry according to your changes.

> I think that default config files should assume fso-usaged.
> However, config package should not depend on fso-usaged, to avoid circular 
> dependency.

At the moment the cfg packages depend on the binaries and not the
other way arround. I think this is against Debian Policy?

> 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 :).

perhaps we should ask upstream to have a /etc/frameworkd.d/, this
would make packaging much easier :)

> 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 can tell there are differences between gta01 and gta02
configuration. Apart from this I think we should split configuration
out of the framework, because it simplifies cfg - at least when we
want to support non openmoko smartphones in the debian fso package.

The problem is, that we currently generate the generic cfg from
frameworkd src package and all other configuration packages from a
seperate src package. I think all cfg binary packages should be
created by this src package. I'm currently working on the
dependencies, which are kind of complicated. At the moment the
config depends on fso-frameworkd. Like this user can install
fso-frameworkd without any cfg.

> 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.

yep :)

> 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.

Ok, I will revert this change then.

> 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 will change the pkg according to this once I get some free time.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20091022/e84ef888/attachment.pgp>