Re: goals for woody ? (Re: Release Date of Woody?)
>>"Marcin" == Marcin Owsiany <email@example.com> writes:
Marcin> How about making debconf obligatory?
Uhh, we are by no means close to making that a release
goal. It is a desirable long term goal, perhaps, but not for
woody. And mandatory is something that may never actually happen for
Despite popular belief; debconf is neither a panacea, nor does
it presume to solve all user interaction issues. This has come up
before, let me rehash some issues I had with the assumption that
debconf can allow us to have a non-interactive install.
How about this scenario: Package A needs to run a program from
Package B, and let the user choose between alternatives in order to
configure package A to be in a working state. Unfortunately, the
alternatives are not known before the program is run. Package A is a
daemon process, so we stop the daemon before unpacking, and we start
it after configuring. We pre-depend on package B, so that our program
is available to us.
This all works under our current mechanisms. How do you handle
this under the new scheme? When can we ask the questions? Unless we
are prepared for a larger down time window, we can't make the process
non-interactive until the end. The user should be able to choose
which way the installation process goes.
Let me try a concrete example; the kernel image postinst, and
see how far we get. These are the questions the kernel image
postinstall asks, and I have tried to figure out if the question can
be pre asked.
------------- Question depends on test on fie system
/ ------------ Question important (IMHO)
|/ ----------- Depends on previous answer
||/ ---------- Needs run time test
|||/ __ can be pre asked
X...........Y 1) Ask to remove /System.map files
.X Y 2) ask to prepare a boot floppy
XXX.........Y 3) ask which floppy drive to use
.XX.........? 4) do I need to format the floppy?
.XXX........N 5) Insert floppy, hit return
.XXX........N 6) failure, retry?
.XXX........N 7) failure, you have formatted floppy?
.XXX........N 8) you have floppy, hit return when ready
.XXX........N 9) Failure writing floppy, retry?
.XXX........N 10) failure, hit return when youhave new floppy
XX..........Y 11) if conf exists ask if we should run $loader with old config
XXX.........Y 12) Or else ask if a new $loader config
.XX.........Y 13) Or else ask if loader needed at all
.XX.........N 14) Install boot vlock on partition detected at runtime
XXXX........N 15) Install mbr root disk
.XXX........N 16) Failure writing mbr, do this manually, hit return
.XX.........N 17) make that partition active?
Being told that this should not be done during installation of
the kernel-image is not what I consider useful; installing kernel
images (yes, multiple images, in succession), and having a sane and
bootable system with the just installed image bootable is a good
thing (people who do not like this behaviour can already turn this
Help a swallow land at Capistrano.
Manoj Srivastava <firstname.lastname@example.org> <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