El Thu, Feb 03, 2005 at 05:58:56PM -0800, Vagrant Cascadian va escriure:
> > r> Alle 11:24, mercoled? 26 gennaio 2005, Sergio Talens-Oliag ha scritto:
> > >>After all packages are installed, we copy the original file to a place we
> > >>can recover it from, like:
> > >>
> > >>/etc/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
> > >>
> >
> > r> I think that for Policy compliant the original config files must go
> > r> in /var/lib/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
> >
> > r> it seems a good keep-it-simple-stupid approach, i like it.
> >
> > Yes, good idea Sergio. I like it too. I feel it satisfies most of the
> > needs of CDDs. This is just first impression though.. need to digest
> > it a little bit :)
>
> one thing i wonder is how to be sure it's the original configuration
> file? whatever is there when the CDD gets installed? can we compare
> against the package's configuration file somehow?
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.
- If the file is generated by debconf we probably have the md5sum on
/var/lib/ucf/hashfile (that is, if the package uses ucf) and we can do the
same as above.
- If the file was generated by the user the original version is the current
file ... ;)
> what if we have multiple CDDs on one machine- one CDD may see the other
> CDD's configuration file as the "original".
Yes, we have a problem then, I'm aware that the model is mainly appropiate
for a single CDD or, at least, for not conflicting tasks, but anyway we have
some options:
- Apply only one customization to each file: when the user chooses CDD tasks
he does it assigning priorities and once a task changes a configuration file
other tasks don't do it... that is problematic, but can work if we warn the
user about the conflicting files.
- Apply multiple customizations in order (lower priority tasks first): if we
detect that a file has already been modified we can try to customize the
modified version, generate a new file based on the original one or leave
it with the previous customization. Depending on how the user wants to
handle this issues we can let him choose interactively or leave the system
with the first option that succeeds (of course we will have a tool to
report how the configurations are in a given moment).
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.
> it might be good, though maybe complicated, to provide CDDs with some
> mechanism to know if it's a CDD-tweaked configuration file... something
> similar to dpkg-diversions(at least in concept, i have no idea how it is
> implemented).
The idea is to have something similar to the functionality provided by
diversions and alternatives, keeping checksums of all configuration files
modified or generated by CDD tasks and a history of the customizations
applied.
To be able to detect user modifications, undo changes or warn him before
upgrading modified files, we will need, for each file modified using this
technique, which file was the original one, who has modified it and in which
order.
Greetings,
Sergio.
--
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