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
