On Sat, 6 Jan 2001, Russell Coker wrote: > You don't have sym-links to the root directory? Why not?
There's absolutely no need or necessarily a desire to do so; besides which, the point is moot: if you're in the automation arena, you'll notice that kernel-package no longer produces them. Trying to create a GUI interface to something with the free-formality and complexity of lilo.conf, even totally disregarding the idea of trying to allow interoperation between a human editor and your configurator, is /seriously hard/ to achieve plausibly. Things get worse, though: you try to model the configuration setup in a strange orthogonal-linear fashion, which is destined to fail -- inelegantly. If anything, a structure more similar to pppd's configuration would befit what you're trying to do. I think you need to go back to basics: to really carefully consider exactly how you might most efficiently model the configuration in as much depth as you feel you need, and then how best you might represent that within debconf, if debconf is what you want to use. And then, I'd think carefully about how, at a lower level, you might best effect some degree of interoperability between a human editor and your configuration mechanism. Consider the following situations: * human prefers editing all files by hand, beautifully laid out in every typographical sense; * your configurator generates a perfectly adequate file, and human has no desire nor understanding to ever modify it in any way; * your configurator is not advanced enough to cater for the user's needs; not even close; * your configurator generates a file that's /almost perfect/, but just needs one or two tiny tweaks (like adding `lba32', say) -- human wants to use your program to do the hard work but preserve the tweaks. You could perhaps model this by offering a few options during the postinst: * ignore lilo.conf and never touch it again, leaving it all to the human; * generate a template file in /etc/lilo.conf.template, and then switch back to mode (1); * generate the master file, /etc/lilo.conf. (I hasten to add that the default should be the first: an upgrade should /never/, /ever/ corrupt a working lilo installation.) This scheme, as you can see, totally skips round the problem of interoperation between human and script editors -- for which you'd need to invent a parser that could read in lilo.conf and present it in a form which your program fully understood. If you're going down that route, you might want to even analyse the syntactical sugar used by the human and try and model it in the entries your program modifies. Alternatively, you could avoid this whole minefield by desisting. I haven't even /begun/ to describe the complexities of implementing a proper scheme -- herein is mentioned only the very tip of the iceberg. If you're confident, please do go ahead -- the result might break some ground. I feel, though, that lilo is probably trickier than most of the other slightly easier and simpler examples of this sort of thing, and for the time being, it might be better avoided, or at least /not/ shoved in people's faces as it now is: never the best way to endear people to your work [viz. M$]. c.