[pkg-fso-maint] breakage ahead

[Jonas Smedegaard]

On Wed, Jan 13, 2010 at 04:38:51PM +0100, Heiko Stübner wrote:
>
>Am Mittwoch 13 Januar 2010 schrieb Nikita V. Youshchenko:
>> > The problem is to find a way to provide the user with a ready-to-go
>> > config for his phone.
>>
>> I would vote for having config files for all devices supported by a
>> particular daemon in the package provided by that daemon. E.g.
>> under /usr/share/packagename/configs/
>>
>> Then postinst could detect current hardware and copy or symlink needed
>> config to /etc.
>>
>> I think that this appreach is cleaner than alternatives, and will scale to
>> number of devices that may become supported in forceable future.
>and when the user wants to use some completely different config he could simply
>put a real config in place of the symlink in /etc/freesmartphone

Short story: Avoiding default dpkg conffile quickly gets complicated!

Symlink
-------

Problem is the user may not be aware that a symlink, not a real file, is 
being edited, so may end up editing a file that is then automatically 
reset when package is updated.


Copying
-------

If the package provides config, then package must maintain config and 
clean up again when package is purged.


Leaving out
-----------

If the application/daemon supports loading defaults from 
/usr/share/<pkg>/config and optional overloads from /etc/<pkg>/config 
then that's the most elegant approach.  This is generally called 
multilayered config.

If application/daemon only works after user has manually copied over 
some default config and adapted it, then it is pretty inelegant IMHO.


  - 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/22f8d804/attachment.pgp>