[pkg-fso-maint] breakage ahead

Jonas Smedegaard dr at jones.dk
Wed Jan 13 12:09:35 UTC 2010


On Wed, Jan 13, 2010 at 12:03:33PM +0100, Sebastian Reichel wrote:
>On Wed, Jan 13, 2010 at 11:02:06AM +0100, Heiko Stübner wrote:
>> Hi,
>>
>> Am Mittwoch 13 Januar 2010 schrieb Jonas Smedegaard:
>> > conf-files cannot use alternatives system. Using other methods is 
>> > also tricky to do right - i.e. preserve user customizations etc.
>> thanks for the hint
>>
>> > The IMHO best - i.e. simplest and most reliable to maintain - is to 
>> > ship with the software using it a plain configfile, tagged by the 
>> > packaging mechanisms as a conffile.
>> The problem is to find a way to provide the user with a ready-to-go 
>> config for his phone. The daemon-configs contain only settings to 
>> make the daemon work on one specific phone. So the user can't really 
>> change the behaviour of the daemon with config settings as there is 
>> really only a correct one [works or not :) ] for each specific phone.
>>
>> So a solution would be nice to keep the user from having to edit a 
>> config where he has no real choices and can only copy settings from a 
>> README :-)
>>
>> Ideas?
>>
>> Heiko
>
>I guess it would be the best to put the configuration files per
>daemon package and add debconf rules to the packages to configure
>the important stuff. In fso-usaged's case this would be just
>lowlevel = {none, openmoko, kernel26} as far as I can see.
>
>I'm not sure if this is against the Debian policy or if it even
>works, but it may be a nice idea to setup the device type in
>one of FSO's base libraries, so that it must be configured only
>one time. The other daemons could then ask for the device type
>configured in the base library to configure their own cfg.

If manipulating config files through debconf, then they should *not* be 
marked as conffiles but instead use e.g. ucf.

It is *not* easy to do right.


Also, beware that if including a conffile in a *library* package, then 
you run into problems when soname changes. I believe it is impossible to 
do right - and that the proper approach for soname-changing libraries 
that includes a config file is to ship that file in a separate binary 
package that the library package then depend on.

(I ran into this with uw-imapd but since the config file was only 
optional I picked the simpler route of not providing that conffile at 
all).


  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20100113/af8c43cf/attachment.pgp>


More information about the pkg-fso-maint mailing list