Re: lilo.conf
On Saturday 06 January 2001 16:38, Marc Wilson wrote:
> Ok, lets answer these in order:
>
> True. I missed that on debian-devel. I have been pointed to the message.
> I apologize.
>
> No, /etc/lilo.conf.old does NOT have a backup. It has a copy of a
> configuration I was using months ago. More than likely I'd made a copy of
> my configuration for some reason under that name, although I don't remember
> doing it. I do recognize the configuration in that file as being an old
> one, however. Does yours not overwrite a .old file if it finds one? Why
> was a backup necessary in the first place? I wasn't asked if I wanted my
> configuration overwritten. Why didn't it auto-run the debconf front-end,
> for that matter, which would have at least been an indication that, hey,
> you'd better save that file!
These are good points. I will release a new version soon which I think will
address all your concerns. I will email the package to you first for your
feedback.
> Assuming that everyone uses kernel-package is stupid. Plain and simple.
> Not bothering to look at the running configuration to make SURE is even
> worse. If you're going to throw the "you're running unstable" shill at me,
> I'm going to throw right back at you the fact that people running unstable
> are likely to compile their own kernels. And horrors, they might actually
> download a tarball and do it that way. Why would I want a deb of my
> kernel? I'm not going to run it anywhere else, so what good is portability?
I make Debian packages for all of my kernels, even if I don't plan to use
them on more than one machine. Then everything is cleanly managed by the
packaging system and I can easily remove the package to remove all the files.
> Certainly I do. That's why I run unstable. But unstable doesn't mean that
> the maintainer makes a deliberate attempt to lunch your box. "Sorry for
> the data loss?" (quote from postinst) You KNEW this was going to do this.
I didn't expect any data loss. The original author of the debconf code put
that in as a warning that it might result in a non-bootable config. No
matter what I do there is always risk of this. I expect that every new
version of LILO will have some machines it doesn't work on, not as a
packaging issue but from the issue of assembly calls being compatible with
BIOS code on various machines.
Also have you considered using the new testing release? Testing has packages
that have been unchanged in unstable for 2 weeks. Count on the fact that the
lilo package will be changed more often than that until most people agree
that it's good enough. This means that it won't be in testing until these
issues are all resolved.
As a side note. There have been three packages (that I know of) in unstable
in the last 6 months which have made it impossible to login to machines that
have them installed. In two cases those packages had bugs which came back on
more than one occasion. I admit that in regard to one of the packages I got
a bit edgy after my machine became unusable for the third time in a week, but
I felt no need to start flaming the package maintainers. Note that a bug
which makes it impossible to login is considerably more serious than a
lilo.conf error.
> As for filing bug reports, I note that several people already have on these
> issues. Should I add another? Would it have helped?
Do you really think that flaming me repeatedly helped at all? I've spent
about an hour responding to your flames. This means that the time when these
bugs get fixed is delayed by one hour of coding time. One hour of coding
time can be 10% of a day or it can be an entire week depending on what other
things I have to do. At the moment I can't be certain how many iterations it
will take to get this right.
> You haven't MADE a request for my lilo.conf. Here it is:
Here is a section of text from your third flame (the first public one). It's
where you quote my message. I have changed the relevant part to upper case.
------
I am working on the Debian package of lilo and am writing code for
auto-generating lilo.conf files.
Below is an example of the type of lilo.conf that can be generated. The
debconf asks whether you want boot or boot-menu as the boot loader, it asks
what VGA mode you want, what parameters to append, and what DOS partitions
to
setup with the "other=" settings. The rest is inferred from the running
system.
IF YOUR LILO.CONF HAS THINGS THAT AREN'T IN THIS WHICH YOU THINK SHOULD BE IN
DEBCONF THEN PLEASE DO AN ANONYMOUS FTP TO IVANOVA.COKER.COM.AU AND UPLOAD IT
to the incoming directory. I'll try and make the next version do what you
require.
------
> I'm not planning on being a developer. I *am* planning on keeping my boxen
> running.
Of course. Programming is hard work. Flaming people is easy.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: