Re: LILO 21.6-2

[Chris Rutter <chris@willow.armlinux.org>]

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.