[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: How to handle configuration files and updates on the cddtool

El Fri, Feb 04, 2005 at 12:43:08PM +0100, David Schmitt va escriure:
> On Friday 04 February 2005 10:57, Sergio Talens-Oliag wrote:
> >   Well, we are sure that we will have the file the user had before
> > installing the CDD and generally we can know if it has been modified or
> > not:
> >
> >   - If it is a file included on a package we have the original md5sum on
> > the /var/lib/dpkg/info/PACKAGE.md5sums, so we can verify if it has been
> > modified or not and warn the user if it was.
> Not all packages include md5sums. Also I'm not too sure if those that do, 
> include md5sums for their conffiles and their generated-in-postinst ones.

  You have removed the other options on your comment .. ;)

  Anyway, thanks to it I've noticed that the debsum files on
  '/var/lib/dpkg/info/PACKAGE.md5sums' are not mandatory, and that we have to
  check '/var/lib/dpkg/info/PACKAGE.conffiles' which IS mandatory for
  configuration files, leaving the check as:
    - Search file on '/var/lib/dpkg/info/*.conffiles'
    - If not found, search on '/var/lib/ucf/hashfile'.
    - If not found, search on '/var/lib/dpkg/info/*.md5sums'.
    - If not found, our copy is the original file.

  The idea is that if we don't have the information about the original file
  the preexisting one will be considered the original and if it causes problems
  the problems will also exist on a non customized installation.
  Remember that on upgrades we will undo customizations, leaving the pre-CDD
  file on its place (we will only warn the user if we detect that our original
  file was modified), afterwads we will have two cases:

  1. If the upgrade includes the file, the old pre-CDD file is overwritten
  without questions (as happens on a normal Debian).

  2. If the upgrade generates or changes the new file without using ucf, it
  will do it against the pre-CDD version, as on a normal Debian installation.

  After the upgrade we will reaply customizations and we will register the
  current file versions as the first time (copy current version)

> >   Anyway, keep in mind that this problem is also present for the debconf
> >   preseeds, and on that case we are forced to decide which preseed wins
> >   (presseding twice overwrites old values).
> >   My idea is that, in the future, we will only need to define a CDD
> > choosing from a set of task templates that can use special tools to resolve
> > this kind of problems by package or, at least, try to avoid problems
> > providing tasks that we can install for multiple CDDs at once (our CDD
> > Description package can depend on another CDD Description and have our
> > tasks depend on other CDD) ... I'll update my CDD Description file format
> > to include this option.
> In the long term, I think CDDs should aim at integrating (most) of their 
> changes into Debian proper. Therefore Debian (IANADD) perhaps should think 
> about providing the basic debconf overlays in the official distribution where 
> the different CDDs can coordinate. This would automatically lead to the need 
> of having mechanisms for "debconf patch ordering" which could then be 
> naturally extended by CDDs outside of Debian proper.
> Hmmm, thinking about it further, I probably just said "yes" in a very 
> complicated manner ;)

  Well, first I'ld like to implent the system I describe and see if it
  works for the simple case, once it does we can think about more complicated
  cases and integrating things into Debian as a whole.



Sergio Talens-Oliag <sto@debian.org>   <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69

Attachment: signature.asc
Description: Digital signature

Reply to: