[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: goals for woody ? (Re: Release Date of Woody?)



>>"Marcin" == Marcin Owsiany <porridge@pandora.info.bielsko.pl> 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
 all packages. 

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

        manoj

-- 
 Help a swallow land at Capistrano.
Manoj Srivastava   <srivasta@debian.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



Reply to: