mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] Change some install_alternative to install_config
Date: Thu, 15 Mar 2012 10:43:13 +0100	[thread overview]
Message-ID: <20120315094313.GN20481@pengutronix.de> (raw)
In-Reply-To: <4F6108DA.2000002@gmail.com>

On Wed, Mar 14, 2012 at 04:08:42PM -0500, George McCollister wrote:
> On 03/14/2012 10:10 AM, Benoît Burnichon wrote:
> >To avoid loss of configuration when upgrading packages with default
> >configurations.
> This is a tricky subject. On some embedded systems it may be
> expected for a user or configuration utility to change some configs
> while not other configs. On some embedded systems it may be
> impossible (or unlikely) for the user to modify configurations.
> 
> When a package is upgraded sometimes new configuration options are
> added and sometimes they are deleted, sometimes the format of the
> configuration is changed entirely or moved to a different location.
> Other times the upgrade is just a maintenance release and only
> contains minor fixes.
> 
> If you mark a file as a config file by default opkg won't upgrade
> that file during a package upgrade, even if the user never made any
> modifications. At this point you are basically deciding to leave the
> original file unchanged and putting the burden of merging old and
> new config files on the user.

Exactly, and last time I checked opkg didn't have a way to forcefully
overwrite the old config file without prompting.

> We've dealt with this by leaving install_alternative for all config
> files by default and only making custom rules with install_config
> for files we intend for users to change. For our device it makes
> sense for instance that a user may want to modify ntp.conf to add an
> ntp time source (we provide a web based utility to do this), yet it
> makes no sense for a user to change the dbus configuration. If
> during the course of a version upgrade a configuration option is
> renamed, eliminated or added, we provide a .postinstall script to
> modify the user configuration and make the required changes so the
> user doesn't end up with a broken device.
> 
> Ultimately I think a better frame work is needed to handle
> management of configs. Suppose your user wants to backup his
> device's configuration files to a PC. Then suppose said user's
> device is burnt to a crisp when lightning strikes an improperly
> arrested antenna (this has happened). He orders replacement but it
> arrives with new firmware. He sends his backed up config files to it
> from a and it doesn't work because the name of a setting in one of
> the config files changed.
> 
> Ideally you could provide a single script to migrate a config file
> from one package version to another. This script could be used when
> the package is upgraded OR when users send configuration files to
> the device.

An idea I just had: maybe introduce a new install_* command. And then,
depending on an option in ptxconfig, install the file as a config file or
not. Also, you'll need to create individual patches for each package, and
the current patch contains far too many files that are certainly not meant
to be changed by the user.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

-- 
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2012-03-15  9:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 15:10 Benoît Burnichon
2012-03-14 21:08 ` George McCollister
2012-03-15  9:43   ` Michael Olbrich [this message]
2012-03-15 10:14     ` Benoît BURNICHON

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120315094313.GN20481@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox