Manoj Srivastava <[EMAIL PROTECTED]> writes:
[...]
> 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.
This might be the way to go, but as it puts additional burden on the
package maintainers.
Providing configuration data before starting the install has obviously
the advantage of minimizing the time a package is non-functional
(i.e. unconfigured, or not working in the intended way), compared to
providing the data afterwards.
If the user wants to change the decisions made before installation
(i.e. after finishing package selection and before starting
installation) after he has finished it, it would be nice if he could
do it the same way. The query script should be run, answers stored in
a database, and then postinst configure be run again. Even better if
this would somehow integrate with using linuxconf/coas/whatever.
[...]
> 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'm not sure how you want to do that.
Some packages show notices of the form "look into file xyz after
installation".
With user-configured I didn't mean the configured state of dpkg. After
installing a package like samba, debian provides a do-nothing
configuration (or a configuration that does something, but often not
what the user wants, which is the case with autofs).
One could provide a smb.conf before starting the installation (which
certainly could be an option for experts or when installing a compute
farm), but
- programs like linuxconf/coas don't work that way
- sometimes the user wants to try out/correct/try again
- sometimes it's better to have all the documentation at hand before
going through the configuration of a package
- sometimes a package includes helper programs that aid in
configuration. Some network perl library package offers to verify
host names when they are entered.
My conclusion is that it's often desirable to first install the
packages (including the debian-configuration, which should guaranty a
sane state) and then user-configure them to make them really work the
intended way (and perhaps climb a learning curve while doing that).
The package installer could maintain a list of the packages to be
user-configured, maybe associated with some configuration program.
> I agree about important notices; however, that is fairly simple to
> implement; and there is not much of an design issue there.
Ok, some time ago I made a proposal to put a severity prefix in front
of each output line (or maybe before a block of lines?), and to
automatically tag unprefixed lines, depending on if they come through
stdout or stderr (which means letting dpkg redirect the script output
and installing a filter), and to automatically capture the output of
the installation run somewhere.
Anyone having a better proposal?
(I'm not sure there are no design issues here)
> 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?
It's a better aproach than the current one, but sometimes it's neither
the old (modified) one or the new one, but the old one with some or
all of the modification the maintainer made to the provided conf 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).
that seems to be the core problem.
>
> 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.
I'm not sure if I understand you correctly. Do you want the user to
decide if the old or new version should be used based on a description
of the changes the package maintainer did? Or do you want to do a
merge of the users old conffile with the package mainainers changes?
In many cases I'd like to view my own (nonexisting) changelog of the
conffile too, to compare it to the changelog of the package maintainer
:-).
I have another 2 ideas
- let the package maintainer decide which conffile to use in an
unattended installation. After installation present a list of
old/new conffiles and status and let the user look it over and do
the merge or whatever (yes, again a to-do-list :-)).
- add deltas of the conffile versions to the deb archive to make a
3-way merge possible (doesn't sound like a really good idea, but
3-way would be nice). Or if it's true that linuxconf uses RCS, that
might be a better way for such a merge. Or even, use coas (it's
concepts seem to be better suited to this than linuxconf's) to query
the current configuration and change it to meet the new
requirements. This could all be done before installation/upgrading
or non-interactive during installation (no to-do-list :-))).
It seems to me that for upgrading asking all questions / edit
conffiles before installation is the wiser approach, while for
first-time installation getting to a sane state quickly and helping
the user do the configuration (or should I write customization)
afterwards is better.
>
> There. Not bad for an off ther cuff answer, is it?
Is this like Linus's "tested" approval? ("compiles on my machine") :-))
ciao
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
