Hi,
>>"Andreas" == Andreas Degert <[EMAIL PROTECTED]> writes:
Andreas> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> I prefer the approach to ask questions first, and configure as
>> it installs. If we are spending time to do this, we should do this
>> right.
Andreas> In general, you can't ask all questions first; you can ask
Andreas> some questions, then unpack and debian-configure the
Andreas> packages, but then you still have to do a lot of
Andreas> configuration (using an editor or some configuration
Andreas> programs that "ask questions").
Why can't you ask all the questions first? I am too thnking of
the kernel image package. I can easily design a framework that
gathers all the data a priori -- and yes, you have a point;
Andreas> because the questions depend on the state of the system which might be
Andreas> different before installation than when the postinst is actually
Andreas> executed.
I may then need to ask extra questions in a what if
manner. All it takes is a little bit of thought while creating
the questions. And the databse so generated can be truly machine
independent, and be used to replicate machines in a compute farm.
Two ver worthy birds with one stone.
Therefore, I do think that Ians proposal handles the points
you mentioned.
Andreas> I'd like to integrate more of the bookkeeping tasks into the
Andreas> debian system, like being able to display a list of
Andreas> warnings/errors after installation is finished, and a list
Andreas> of packages that still have to be user-configured.
I want to eliminate that list. I agree about important
notices; however, that is fairly simple to implement; and there is
not much of an design issue there.
Andreas> how do you deal with existing versus new config files during an
Andreas> upgrade (or how would you like to deal with it)?
Hmm. Asking ahead of time may not be a satisfactory solution
unless one can compare the two sets of config files. Gack. Well,
rather than dpkg asking a bland question, we need the package
maintainer provide a text lsiting changes in the conf file, and use
that to prompt a user whether they want the new file?
We can't probably default to the old file (the new version
of the code might not be backwards compatible); or the new version
(the package may not be useable without changes).
Ifg we want to make non interactive installs a reality, we
have to put in work to support it -- and that means creating a change
text for each conffile. Lintian can check whether the developr has
provided the change text; it can even be in changelog format, so dpkg
can extract the changes since a particular version of the conffile.
So, if the conffile has changed, dpkg looks to see the version
that was installed, grabs the changelog, and asks the installer
whether they accept the changes.
There. Not bad for an off ther cuff answer, is it?
manoj
--
"Help save the world!" --Larry Wall in README
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
