> > 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. >
I did not checked into opkg's code but there supposed to be a '-force-maintainer' option to do this. Otherwise the '-force-default' prevents prompting before leaving the file as is. So, if opkg is run manually without arguments (apart the install or upgrade command), it will prompt before leaving a file as is and check with diff what has actually changed between the two versions. > > 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. > > The way it is does not prevent the maintainer to provide such a script on a config file. Actually, it is done like this on a debian distribution, isn't it ? I think that maybe a prerm script is then needed to check the validity of the current config file. If it has not changed, delete it and take the one in the package. If it is upgradable, perform the upgrade in a tmp config file and postinst script install this tmp config file back to its place. > > 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. > > I totally agree with that. We developed a script that records all needed configurations files at the same place as well as original configuration to be able to return to a known state (with the funny 'configator' nick name...) We do have had issues with ipkg upgrade because it replaced the ipkg.conf config as well as the /etc/network/interfaces file. I would have preferred the upgrading process to stop instead of having all packages in their default configuration. > > 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. > I have grepped all install_alternative in the rule directory and changing the ones I suppose should be install_config. It can be split into a big bunch of packages patches but I did not want to flood the ptxdist mailing list. Ben ________________________________ Ce courriel et toutes les pièces jointes sont confidentiels et peuvent être couverts par un privilège ou une protection légale. Il est établi à l’attention exclusive de ses destinataires. Toute utilisation de ce courriel non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse préalable. This email and any attachment are confidential and may be legally privileged or otherwise protected from disclosure. It is intended only for the stated addressee(s) and access to it by any other person(s) is unauthorized. Any use, dissemination or disclosure not in accordance with its purpose, either in whole or in part, is prohibited without our prior formal approval. -- ptxdist mailing list ptxdist@pengutronix.de
