Jan Stary <h...@stare.cz> wrote: > > 1) If you edit that file yourself, > > Is there any other way this file is supposed to come to existence > (except the one containing the default answers, which sysupgrade > writes itself) beside editing it by hand?
sysupgrade creates it, exactly as it wants it to be. If you edit it, you are no longer using sysupgrade. You are on your own. > > how can you say you are using sysupgrade? > > Perhaps I was unclear: I took the response log of a sysupgrade run > (as mailed afterwards) and created /auto_upgrade.conf from it. > I am not touching sysupgrade itself, obviously. Ah, you edited the file. Then you are not using sysupgrade. You are using your own process, and you need to understand all the consequences. misc@ owes you nothing. > > sysupgrade manages the whole process. When you subvert a program, you are > > responsible. > > Is creating /auto_upgrade.conf considered subversion? No. You can create your own /auto_upgrade.conf But if you create it, it is not sysupgrade that created it If you create a file which doesn't work, have you considered blaming the creator of the file? > > Especially when it is not documented what will happen. > > sysupgrade(8) says > > /auto_upgrade.conf Response file for the ramdisk kernel. > > I agree that only documents the file is recognized to exist. But you are not using sysupgrade. Why do you refer to the sysupgrade manual page? You have placed *your own ideas* of what should be in that file. sysupgrade does not use ambigious question=answer lines. But you do. You are acting completely clueless here. > > 2) You assume you can provide multiple answers to a question -- > > how do you expect this to work? > > I naively assumed the undocumented file replaces > the interactive dialogue of a bsd.rd upgrade. My bad. If it was replacing the dialogue 1:1, then the lines would only need to be answers. But every line is question = answer. Obviously, the parsing of this won't keep-state then, and it acts as either first-match or last-match, so you cannot repeat questions. > > 3) see _autorespond in install.sub > > Thank you. > > My original problem is that some machines are small/slow enough > to warant not having e.g. the X sets, and I am trying to persuade > sysupgrade to do that. Is there a user-visible way to do that > via /auto_upgrade.conf? what the hell does "slow" have to do with installing files you won't use? Buy a bigger machine. Or use Linux, which will mean you need to buy a bigger machine. I'm dead serious -- OpenBSD is a small enough operating system that we don't need to bend-over for people who want to use it on ridiculously miserly systems. We have tradeoffs to make and I see NO POINT in focusing on people who's machines are that small.
