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.
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