>> On Fri, 18 Apr 2003 20:03:04 -0400,
>> David B Harris <[EMAIL PROTECTED]> said:
> On Fri Apr 18, 06:37pm -0500, Manoj Srivastava wrote:
>> If you use ucf like mechanisms, and you acpet the first debconf
>> generated file, then you will never be asked to over write your
>> file -- since the md5sum of the installed file shall match the
>> previous maintainer version. Bingo, we cater to all these use
>> cases at once.
> Wouldn't that only be accurate if the postinst generated an
> identical config file every time?
Nope. When you accept a config file, your md5sum uis the same
as the one generated *then*. Next upgrade, if the postinst generated
file is different, it shall replace yours again -- since your file
will still match the stored md5sum.
If i did not work this way, ucf would not be anywhere near as
useful.
manoj
--
... C++ offers even more flexible control over the visibility of
member objects and member functions. Specifically, members may be
placed in the public, private, or protected parts of a class. Members
declared in the public parts are visible to all clients; members
declared in the private parts are fully encapsulated; and members
declared in the protected parts are visible only to the class itself
and its subclasses. C++ also supports the notion of
*_______friends*: cooperative classes that are permitted
to see each other's private parts. Grady Booch, "Object Oriented
Design with Applications"
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
