Re: policy changes toward Non-Interactive installation
Joey Hess [EMAIL PROTECTED] writes: Manoj Srivastava wrote: ... Quite simply: This type of thing can not be handled before unpacking, so it isn't. Debconf allows package to ask questions in their postinst, this is just *strongly* discouraged. See the realplayer installer for a package that (rarely) has to use debconf interactively in its postinst. My option on this that packages that need to ask questions after unpacking should not be setup toether with packages that don't need that. There should be a preconfigure and postconfigure and the unpacking inbetween those should be non-interactive. There is no need to stop all packages from being configured just because the kernel-image packages needs some input. Downtime of services should be minimal. Let me try a concrete example; the kernel image postinst, and see how far we get. These are the questions the kernel image postinstall asks, and I have tried to figure out if the question can be pre asked. == - Question depends on test on fie system / Question important (IMHO) |/ --- Depends on previous answer ||/ -- Needs run time test |||/ __ can be pre asked / | | X...Y1) Ask to remove /System.map files .X Y2) ask to prepare a boot floppy XXX.Y3) ask which floppy drive to use .XX.?4) do I need to format the floppy? .XXXN5) Insert floppy, hit return .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN8) you have floppy, hit return when ready .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy XX..Y 11) if conf exists ask if we should run $loader with old config XXX.Y 12)Or else ask if a new $loader config .XX.Y 13) Or else ask if loader needed at all .XX.N 14) Install boot vlock on partition detected at runtime N 15) Install mbr root disk .XXXN 16) Failure writing mbr, do this manually, hit return .XX.N 17) make that partition active? == Right. This is obviously a rather important package, which *cannot* fail, plus is is very dependant on the actual state of the system. As such, the best you'll be able to do is allow a few questions to be pre-asked, and defer the remainder to the appropriate maintainer script. I think that the configuring the package twice is not so good. If you know that you need to bother the user after unpacking anyway, lets do it all in one step. (BTW, I'm ccing this to Wichert and AJ as a sterling example of why debconf has to continue to support this type of thing in maintainer scripts. I think both of them don't want it to have this capability, but it is, as you have noted, essential for some packages. May the Source be with you. Goswin
Re: policy changes toward Non-Interactive installation
Joey Hess [EMAIL PROTECTED] writes: Manoj Srivastava wrote: Right. I just do nt see these invariants being very useful. I would much rather have a mk-realplayer package that helps me create a realplayer-blah.deb; and the invariants are then natural and not artificially imposed. When that realplayer.deb is installed, realplayer is installed (duh), and the version of that package tells me what version I have installed. I can then move the .deb to my local apt-able tree, and all other machines in my environemnt can just install this. the ml-realplayer does not have to be upgrade every time realplayer changes. I can install an older verison of real player if I wish (getting it off a CD, or something). Well I for one find being able to make sure I am upgraded to the current version is very useful, especially given the historical buginess of realplayer. Why not just ask in the preinst whether to update or not and provide a script to do so later as well. Also all information needed for downloading could be asked in the preinst as well or not? (Never used that package) Joey If you don't want to download realplayer right now, why are you Joey installing the package? It is not useful hectoring the user when they report a percieved problem. I'm not hectoring, I'm asking a question. That is why my sentence ended with a question mark. A good example for this are the xanim modules. The packages asks whether to downlaod or not and one can start installing the modules at any time as well. May the Source be with you. Goswin
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: Right. I just do nt see these invariants being very useful. I would much rather have a mk-realplayer package that helps me create a realplayer-blah.deb; and the invariants are then natural and not artificially imposed. When that realplayer.deb is installed, realplayer is installed (duh), and the version of that package tells me what version I have installed. I can then move the .deb to my local apt-able tree, and all other machines in my environemnt can just install this. the ml-realplayer does not have to be upgrade every time realplayer changes. I can install an older verison of real player if I wish (getting it off a CD, or something). Well I for one find being able to make sure I am upgraded to the current version is very useful, especially given the historical buginess of realplayer. Joey If you don't want to download realplayer right now, why are you Joey installing the package? It is not useful hectoring the user when they report a percieved problem. I'm not hectoring, I'm asking a question. That is why my sentence ended with a question mark. If we can make it so that people do not have to put thigs on hold, would that not be an improvement? Not really, if it makes it hard for other people to make sure they always have the mose current version. Fine. I prefer to remove this annoyance, though. Consider this an ITP for mk-realplayer. I'll probably steal your code rather than re-invent the wheel. Since your package is not really the realplayer binary, I am asking you to rename it to something else, so the package that mk-realplayer creates would not interfere with your installer. If you want to maintain realplayer, it is yours. I have intended to drop all my contrib packages anyway. If, however, you make it difficult to ensure that a machine tracking stable is not running the current version of realplayer, expect me to send you bug reports. I hereby orphan the package. -- see shy jo
Re: policy changes toward Non-Interactive installation
Joey Hess wrote: If, however, you make it difficult to ensure that a machine tracking stable is not running the current version of realplayer, expect me to Er, make that unstable. -- see shy jo
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Well I for one find being able to make sure I am upgraded to the current Joey version is very useful, especially given the historical buginess of Joey realplayer. Good point. If a location for the free download can be easily determined, can be found, I'll provide a real-player alert script that warns you when new packages appear. Hmm. I need to look at where this is advertized. Perhaps optionally download it for you, and run mk-realplayer on the result. Joey If, however, you make it difficult to ensure that a machine tracking Joey stable is not running the current version of realplayer, expect me to Joey send you bug reports. I see. Well, I guess, given this, I am not going to take over your package. I'll just create a set of packages that conflict with yours. As I said, the itch is getting enough for me to scratch. Joey If you want to maintain realplayer, it is yours. I have Joey intended to drop all my contrib packages anyway. I hereby Joey orphan the package. Sorry. The whole idea of my realplayer package is to be a lower hassle package; it won't periodically bother you. Since you are threatening the next maintainer with bug reports unless they follow your directions, I'm not too keen on taking it. manoj -- Delay is preferable to error. Thomas Jefferson Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: Joey If, however, you make it difficult to ensure that a machine tracking Joey stable is not running the current version of realplayer, expect me to Joey send you bug reports. I see. Well, I guess, given this, I am not going to take over your package. I'll just create a set of packages that conflict with yours. As I said, the itch is getting enough for me to scratch. Joey If you want to maintain realplayer, it is yours. I have Joey intended to drop all my contrib packages anyway. I hereby Joey orphan the package. Sorry. The whole idea of my realplayer package is to be a lower hassle package; it won't periodically bother you. Since you are threatening the next maintainer with bug reports unless they follow your directions, I'm not too keen on taking it. Manoj, you have now several times used loaded words in this discussion: hectoring, threatening. Stating that one will file a bug if a feature one depends on, for reasons one has previously stated[1], is removed, is not threatening. It is a statement of fact, and a privelidge we accord all users of Debian. Until you can stop using loaded words, which feels to me as if you are trying to provoke a flamewar, I will conduct no further discorse with you. Moreover, I find your entire manner in this thread insulting. First you come in and state that the entire design of this package I have maintained for 3 years is broken by design. You raise some valid points as well. Then, without even giving me a chance to respond, you raise the specter of _forking_ my work (I'll probably steal your code), and introducing a duplicate package into Debian, which will only serve to confuse users. Who is threatening whom again? Then you compound these insults by demanding that I rename my package, which has 3 years of prior art, to make way for your vaporware. I avoided flaming you in that last message by deleting said flame out of my laptop's mail queue, and responded by essentially giving you the package, and backing down, asking only that you not break it for *me*, and, presumably, for all the people who have been quietly using it for 3 years without complaining about its grossly bad design. And you respond with the above. I hope you might have a glimmering of an idea now about why I'm upset. I hope _someone_ enjoys maintaining realplayer; I never have. And I sincerely hope it's not you. -- see shy jo [1] And which, for crying out loud, you just agreed with! (Good point.)
Re: policy changes toward Non-Interactive installation
On Fri, Aug 18, 2000 at 01:40:52AM -0700, Joey Hess wrote: Manoj Srivastava wrote: Sorry. The whole idea of my realplayer package is to be a lower hassle package; it won't periodically bother you. Since you are threatening the next maintainer with bug reports unless they follow your directions, I'm not too keen on taking it. Manoj, you have now several times used loaded words in this discussion: hectoring, threatening. [...] Until you can stop using loaded words, which feels to me as if you are trying to provoke a flamewar, I will conduct no further discorse with you. [...] See what working on non-free software does to people? *sniff* It's sad. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpTsP6NDXE19.pgp Description: PGP signature
Re: policy changes toward Non-Interactive installation
On Tue, Aug 15, 2000 at 07:19:09AM -0700, Joey Hess wrote: If you don't want to download realplayer right now, why are you installing the package? E.g., you might have a slow network connection and want to deal with the download later. (So you can finish installing everything else without pausing for an hour to download realplayer.) -- Mike Stone pgpSna8qGpmGP.pgp Description: PGP signature
Re: policy changes toward Non-Interactive installation
On 16-Aug-00, 02:11 (CDT), Joey Hess [EMAIL PROTECTED] wrote: Belive it or not, I know how to safely manage temp files and protect sensitive information with unix permissions. I know you do, Joey, but my concern is that since the permission violation occurs in the backend, when the backend gets replaced by something else that the security by be inadvertently dropped. Would it make sense for the front-end(s) check the effective userid and refuse to run if it's not 0? Steve
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey The package is intended to enforce two invarients: Joey 1) If it is installed, realplayer is installed. Joey 2) If it is installed and current, the current version of realplayer is Joeyinstalled. Right. I just do nt see these invariants being very useful. I would much rather have a mk-realplayer package that helps me create a realplayer-blah.deb; and the invariants are then natural and not artificially imposed. When that realplayer.deb is installed, realplayer is installed (duh), and the version of that package tells me what version I have installed. I can then move the .deb to my local apt-able tree, and all other machines in my environemnt can just install this. the ml-realplayer does not have to be upgrade every time realplayer changes. I can install an older verison of real player if I wish (getting it off a CD, or something). Joey If you don't want to download realplayer right now, why are you Joey installing the package? It is not useful hectoring the user when they report a percieved problem. Perhaps I have a local mirro updated overnight, (with a slow modem, that is the only way to go) and I do not want to wait for a huge realplayer tar ball to download now. Perhaps I did not undertand that I would need a network connection now. Perhaps I had instlled realplayer before, and am happy with it, but I am upgrading my laptop on the plane off my mirror, and do not have a connection. Having realplayer break is not nice. Joey If you don't want to upgrade realplayer right now, why don't Joey you put it on hold? If we can make it so that people do not have to put thigs on hold, would that not be an improvement? Joey The package system allows the things that annoy you to be Joey worked around in a consistent way. Fine. I prefer to remove this annoyance, though. Consider this an ITP for mk-realplayer. I'll probably steal your code rather than re-invent the wheel. Since your package is not really the realplayer binary, I am asking you to rename it to something else, so the package that mk-realplayer creates would not interfere with your installer. manoj -- Then there was the Formosan bartender named Taiwan-On. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey I read your entire message and could not find any examples Joey of things that debconf cannot handle correctly, except of Joey course for conffile change prompting, which it was never Joey designed to do. I think something needs to be done to address this issue. Yes, you can force dpkg to always use the old file, but then this will break applications which require the new file to be installed. -- Brian May [EMAIL PROTECTED]
Re: policy changes toward Non-Interactive installation
On Tue, Aug 15, 2000 at 08:26:50PM -0700, Joey Hess wrote: Anthony Towns wrote: Basically, I'd like to be able to insist that I'm *never* asked a question as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg just get on with installing everything else, although it probably won't at the moment) than get asked a question. That's do-able. Once debconf knows to run postinsts in full noninteractive mode, critical questions that are thus not asked at all, and which do not have their return code caught, will simply cause the postinst to terminate with a nonzero return code. (I think this is better than making _all_ questions terminate it, which is not doable anyway, and also because if a postinst asks a priority low question, say, then that is by definition a question that the noninteractive mode can supply a reasonable answer to.) Well, no, that's not what I want either: I like seeing every question that the postinst thinks I might need to know about. I just want to see them in blocks, preferably beforehand, but at the end if that's the way it has to be. I don't think we've got any examples of non-critical questions that need to be outside the .config though, do we? Something bad happened, and You need to stick a floppy in don't strike me as things that should just be ignored. I'll be happy to implement a debconf/non-interactive-foo (should apply to all maintainer scripts save config, not just postinst, so I need a better name), if people think it will be generally useful. non-interactive-install, perhaps? -maintainer-scripts? However, I presonally feel your specific case of the floppy prompting would be better served by: a) Making the question of low priority. or b) Making the question be asked only once, and this value used by all future kernel packges you install. Or adding a question, do you ever want to make a boot floppy? Especially b. I'm curious about your opinion of an option (c): make a separate mk-boot-floppy script that can be run outside of the postinst after the install. This is the same as what Manoj suggested for realplayer. A bad thing is that, alone, it's not really automatic, you could install the kernel and forget to make a boot-floppy, or you could install realplayer and forget to do what's necessary to actually, well, install realplayer. I think it's more `user-friendly' in general though: realplayer can be annoying the way it is at the moment, and I might change my mind and what a boot floppy later. Ways of getting around the `not really automatic' problem might be: * ask a question in the .config whether you want the program to be run in postinst * always run the programs after dpkg's finished, like update-menus * send a reminder email to root Note that this means the program probably can't really use debconf to do its stuff if it's separate, ie, we'd suddenly be back to boring text prompts and such. Or maybe it's reasonable for some non-maintainer-scripts to use debconf, I suspect it's actually possible at the moment. Having it as a separate program run after dpkg has finished would let you have non-interactive maintainer scripts for all the examples I've seen, I think. Yes, I realise this won't be implemented by the end of the week. :) Oh. Actually... I imagine that if we ever get post-dpkg-run hooks, they'll be invoked something like: run-after-dpkg /usr/bin/update-menus and be run through sort | uniq or something before being called. It might be possible to just implement run-after-dpkg to just run immediately for the moment. Or to re-enable interactive-postinsts, run it, and disable it. Ripping out the logic from update-menus and implementing it as run-after-dpkg could probably work pretty easily too, but wouldn't leave us with anywhere for stdio to happen, afaict [0]. Cheers, aj [0] Although a Unix domain socket could help here ;) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp4P3wsStd8j.pgp Description: PGP signature
Re: policy changes toward Non-Interactive installation
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony To clarify a little: I want to be able to answer the Anthony questions up front, do the install and have it work. If I've This is not somethign anyone can argue with. Anthony made a mistake (like not put a file where I said I did Anthony maybe), I don't mind if it dies and leaves that package to Anthony be configured later or something. I don't want it to pause Anthony and leave the rest of the system unconfigured, though. This is your system, and you should be able to set the defaults that way (/etc/kernel-img.conf -- set do_symlink=NO clobber_modules=YES, do_boot_enable=NO), and you shall never be asked anything by the postinst. Of course, you are then responsible for ensuring your new kernel is booted, but hey, you can't have everything. But other people may have other choices, and I'll fight tooth and nail against any policy changes that leave them out in the cold just cause some people like non-interactive installs. Anthony This is just for my system, I don't really care that much how it works Anthony for other people. Hmm. Not an attitude I can afford to take, I don't think, as package maintainer ;-) Anthony If we go through the `N' questions above, we have: .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy .XXXN 16) Failure writing mbr, do this manually, hit return Anthony ...failure cases, which I want to address as late as possible, rather Anthony than as soon as possible. (The realplayer question is mainly a failure Anthony question too, iirc) Pardon me, I think I don't understand. So, writing the floppy failed, and you want me to just stop doing what I was doing, leaving you with an unbootable system? I am not happy with not offering the user a chance to change the floppy, or quit formatting and going woth a preformatted floppy, or going to lilo instead. If you arrive at these questions, you have asked stuff to be done, and I can't really defer the failure case handling. Sure, I can say that if you asked things to be done, and ignore error recovery, you are responsible for the consequences, but unless that point is driven home, the reputation for rock solid installs may suffer. However, I have no objection in principle to allowing people the *option* of silent installs. My objection is to making silent install the *only* option. .XXXN5) Insert floppy, hit return .XX.?4) do I need to format the floppy? .XXXN8) you have floppy, hit return when ready Anthony ...questions needing a temporary change in hardware. I'd answer no, Anthony I don't want to have a floppy initially, or perhaps want to run Anthony /usr/lib/kernel-2.2.17/make-floppy or something after my install's Anthony completed. Yup. But these questions will still be asked for people who have not set these defaults, and these ned be asked at run time. .XX.N 14) Install boot block on partition detected at runtime Anthony You can detect stuff at runtime from within the .config too; Anthony you should be able to this before the package is actually Anthony installed. At worst, you can say no, don't try to detect it Anthony and annoy me later: this is what it should be. okay? trust Anthony me Easy. Just set up an /etc/lilo.conf (SILO,MILO whatever) and this questioh shan't be asked. But there are people who have not yet done it, and this section is for them. N 15) Install mbr root disk .XX.N 17) make that partition active? Anthony And hence you should be able to ask these beforehand too, I think. Same here. Anthony Basically, I'd like to be able to insist that I'm *never* Anthony asked a question as part of a postinst. I'd rather the Anthony postinst fail (and I'd rather Apt/Dpkg just get on with Anthony installing everything else, although it probably won't at Anthony the moment) than get asked a question. I wuld not object to having such a mode if explicitly asked for. But I refuse to support what happens if you do so. As long as turning this option on is an admittance of responsibility for install failures and their consequences, fine. Anthony would be tidier. For the moment, though, as long as I *can* Anthony say no, I don't want a floppy made and end up with a Anthony non-interactive postinst, I'm happy. I would be happy to work towards this, as long as there is no attempt to outlaw any installation phase interaction. And as long as it is understood that people who ask for a non-interactive install willy-nilly do it at their own risk. manoj -- panic: kernel trap (ignored) Manoj Srivastava [EMAIL
Re: policy changes toward Non-Interactive installation
Brian May wrote: Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve Which reminds me, what sort of security is enabled in Steve debconf? Can any user read the values from the database, or Steve is it limited to root? Not sure about this (on my system only root can read /var/lib/debconf), however: Steve An attempt to use db_get as a regular user, but only Steve because the current backend tries to write a temporary file Steve to var/lib/debconf (I think) (line 229 in ConfigDb.pm, Steve potato version). not sure how well temp files are managed. Belive it or not, I know how to safely manage temp files and protect sensitive information with unix permissions. I was told though, for the purpose of Heimdal-kdc, to put it in the postinst directory. This means it doesn't have to get stored in the database. ie the postinst script does a db_get followed by a db_set. I told you this because you stressed it was very very important. Really sheer paranoia though. -- see shy jo
Re: policy changes toward Non-Interactive installation
Brian May wrote: Just curious, why does realplayer have to do it in the postinst script? Actually, I was misremembering -- it used to do that but I removed it. As another example though, look at heimdal-kdc, which needs to ask for the password, which must be kept as secure as possible. I think we decided it was woth it from a paranoia standpoint to ask for this passowrd in the same program that used it. Debconf should handle passwords safely though. -- see shy jo
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: Actually, this is a particular irritant. Why does it have to be done in the postinst? Why can't I have /usr/sbin/inst-realplayer? So I can download and install at my leaisure, and I do not have to reinstall realplayer installer to get a new copy? Or have the stupid thing want to connect out every time there is a minor upgrade to the installer? The package is intended to enforce two invarients: 1) If it is installed, realplayer is installed. 2) If it is installed and current, the current version of realplayer is installed. If you don't want to download realplayer right now, why are you installing the package? If you don't want to upgrade realplayer right now, why don't you put it on hold? The package system allows the things that annoy you to be worked around in a consistent way. -- see shy jo
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: If there is an alternate mechanism in place it would be time to make it policy. But debconf is not required yet, and it may not fit all potential cases anyway (more on it below). I read your entire message and could not find any examples of things that debconf cannot handle correctly, except of course for conffile change prompting, which it was never designed to do. If you have some specific complaints with debconf's design, please post them, but I'm rather confused about what you're talking about right now, especially since your whole message was very non-specfic and I often couldn't tell if you were talking about whatever Goswin was talking about, or about debconf. How about this scenario: Package A needs to run a program from Package B, and let the user choose between alternatives in order to configure package A to be in a working state. Unfortunately, the alternatives are not known before the program is run. Package A is a daemon process, so we stop the daemon before unpacking, and we start it after configuring. We pre-depend on package B, so that our program is available to us. Yes, debconf can handle this, with no behavior changes *at all* from how it would have traditionally been done. -- see shy jo
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey If you have some specific complaints with debconf's design, please post Joey them, but I'm rather confused about what you're talking about right now, Joey especially since your whole message was very non-specfic and I often Joey couldn't tell if you were talking about whatever Goswin was talking about, Joey or about debconf. I do apologize. I was not talkgin about debconf, since I am not very knowledgeable about it (I have not been keeping up with it, unfortunately). I do intend a flag day soon to convert all my packages over. Given my ignorance of things debconf, could you please elucidate a few points? How about this scenario: Package A needs to run a program from Package B, and let the user choose between alternatives in order to configure package A to be in a working state. Unfortunately, the alternatives are not known before the program is run. Package A is a daemon process, so we stop the daemon before unpacking, and we start it after configuring. We pre-depend on package B, so that our program is available to us. Joey Yes, debconf can handle this, with no behavior changes *at all* Joey from how it would have traditionally been done. This is interesting. Since we do not know what the options are, or even whether to ask the question, before unpacking, how do you handle this? Let me try a concrete example; the kernel image postinst, and see how far we get. These are the questions the kernel image postinstall asks, and I have tried to figure out if the question can be pre asked. == - Question depends on test on fie system / Question important (IMHO) |/ --- Depends on previous answer ||/ -- Needs run time test |||/ __ can be pre asked / | | X...Y1) Ask to remove /System.map files .X Y2) ask to prepare a boot floppy XXX.Y3) ask which floppy drive to use .XX.?4) do I need to format the floppy? .XXXN5) Insert floppy, hit return .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN8) you have floppy, hit return when ready .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy XX..Y 11) if conf exists ask if we should run $loader with old config XXX.Y 12)Or else ask if a new $loader config .XX.Y 13) Or else ask if loader needed at all .XX.N 14) Install boot vlock on partition detected at runtime N 15) Install mbr root disk .XXXN 16) Failure writing mbr, do this manually, hit return .XX.N 17) make that partition active? == Being told that this should not be done during installation of the kernel-image is not what I consider useful; installing kernel images (yes, multiple images, in succession), and having a sane and bootable system with the just installed image bootable is a good thing (people who do not like this behaviour can already turn this off). manoj -- You will gain money by a speculation or lottery. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: I do apologize. I was not talkgin about debconf, since I am not very knowledgeable about it (I have not been keeping up with it, unfortunately). I do intend a flag day soon to convert all my packages over. No problem. Given my ignorance of things debconf, could you please elucidate a few points? Sure. How about this scenario: Package A needs to run a program from Package B, and let the user choose between alternatives in order to configure package A to be in a working state. Unfortunately, the alternatives are not known before the program is run. Package A is a daemon process, so we stop the daemon before unpacking, and we start it after configuring. We pre-depend on package B, so that our program is available to us. Joey Yes, debconf can handle this, with no behavior changes *at all* Joey from how it would have traditionally been done. This is interesting. Since we do not know what the options are, or even whether to ask the question, before unpacking, how do you handle this? Quite simply: This type of thing can not be handled before unpacking, so it isn't. Debconf allows package to ask questions in their postinst, this is just *strongly* discouraged. See the realplayer installer for a package that (rarely) has to use debconf interactively in its postinst. Let me try a concrete example; the kernel image postinst, and see how far we get. These are the questions the kernel image postinstall asks, and I have tried to figure out if the question can be pre asked. == - Question depends on test on fie system / Question important (IMHO) |/ --- Depends on previous answer ||/ -- Needs run time test |||/ __ can be pre asked / | | X...Y1) Ask to remove /System.map files .X Y2) ask to prepare a boot floppy XXX.Y3) ask which floppy drive to use .XX.?4) do I need to format the floppy? .XXXN5) Insert floppy, hit return .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN8) you have floppy, hit return when ready .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy XX..Y 11) if conf exists ask if we should run $loader with old config XXX.Y 12)Or else ask if a new $loader config .XX.Y 13) Or else ask if loader needed at all .XX.N 14) Install boot vlock on partition detected at runtime N 15) Install mbr root disk .XXXN 16) Failure writing mbr, do this manually, hit return .XX.N 17) make that partition active? == Right. This is obviously a rather important package, which *cannot* fail, plus is is very dependant on the actual state of the system. As such, the best you'll be able to do is allow a few questions to be pre-asked, and defer the remainder to the appropriate maintainer script. (BTW, I'm ccing this to Wichert and AJ as a sterling example of why debconf has to continue to support this type of thing in maintainer scripts. I think both of them don't want it to have this capability, but it is, as you have noted, essential for some packages. -- see shy jo
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Quite simply: This type of thing can not be handled before Joey unpacking, so it isn't. Debconf allows package to ask Joey questions in their postinst, this is just *strongly* Joey discouraged. See the realplayer installer for a package that Joey (rarely) has to use debconf interactively in its postinst. Just curious, why does realplayer have to do it in the postinst script? As another example though, look at heimdal-kdc, which needs to ask for the password, which must be kept as secure as possible. -- Brian May [EMAIL PROTECTED]
Re: policy changes toward Non-Interactive installation
Brian May writes: Just curious, why does realplayer have to do it in the postinst script? Binaries need to be downloaded from Real and we can't redistribute them. The user also has to fill out 'personal information' to be able to access the required files. -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: policy changes toward Non-Interactive installation
On Tue 15 Aug 2000, Decklin Foster wrote: Brian May writes: Just curious, why does realplayer have to do it in the postinst script? Binaries need to be downloaded from Real and we can't redistribute them. The user also has to fill out 'personal information' to be able to access the required files. This couldn't be handled by `expect' or similar? Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: policy changes toward Non-Interactive installation
On 15-Aug-00, 02:54 (CDT), Brian May [EMAIL PROTECTED] wrote: As another example though, look at heimdal-kdc, which needs to ask for the password, which must be kept as secure as possible. Which reminds me, what sort of security is enabled in debconf? Can any user read the values from the database, or is it limited to root? An attempt to use db_get as a regular user, but only because the current backend tries to write a temporary file to var/lib/debconf (I think) (line 229 in ConfigDb.pm, potato version). Steve
Re: policy changes toward Non-Interactive installation
Decklin == Decklin Foster [EMAIL PROTECTED] writes: Decklin Brian May writes: Just curious, why does realplayer have to do it in the postinst script? Decklin Binaries need to be downloaded from Real and we can't redistribute Decklin them. The user also has to fill out 'personal information' to be able Decklin to access the required files. Actually, this is a particular irritant. Why does it have to be done in the postinst? Why can't I have /usr/sbin/inst-realplayer? So I can download and install at my leaisure, and I do not have to reinstall realplayer installer to get a new copy? Or have the stupid thing want to connect out every time there is a minor upgrade to the installer? I would much prefer a installer script rather than an installer package which does it in postinst. Actually, this itch may have gotten to the point I want to do something about it, if the maintainers of realplayer are averse to this change. manoj -- You are number 6! Who is number one? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: policy changes toward Non-Interactive installation
Manoj Srivastava writes: Actually, this is a particular irritant. Why does it have to be done in the postinst? Why can't I have /usr/sbin/inst-realplayer? So I can download and install at my leaisure, and I do not have to reinstall realplayer installer to get a new copy? That's not a bad idea. Could you file a bug? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: policy changes toward Non-Interactive installation
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve Which reminds me, what sort of security is enabled in Steve debconf? Can any user read the values from the database, or Steve is it limited to root? Not sure about this (on my system only root can read /var/lib/debconf), however: Steve An attempt to use db_get as a regular user, but only Steve because the current backend tries to write a temporary file Steve to var/lib/debconf (I think) (line 229 in ConfigDb.pm, Steve potato version). not sure how well temp files are managed. I was told though, for the purpose of Heimdal-kdc, to put it in the postinst directory. This means it doesn't have to get stored in the database. ie the postinst script does a db_get followed by a db_set. -- Brian May [EMAIL PROTECTED]
Re: policy changes toward Non-Interactive installation
On Mon, Aug 14, 2000 at 11:38:28PM -0700, Joey Hess wrote: == - Question depends on test on fie system / Question important (IMHO) |/ --- Depends on previous answer ||/ -- Needs run time test |||/ __ can be pre asked / | | X...Y1) Ask to remove /System.map files .X Y2) ask to prepare a boot floppy XXX.Y3) ask which floppy drive to use .XX.?4) do I need to format the floppy? .XXXN5) Insert floppy, hit return .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN8) you have floppy, hit return when ready .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy XX..Y 11) if conf exists ask if we should run $loader with old config XXX.Y 12)Or else ask if a new $loader config .XX.Y 13) Or else ask if loader needed at all .XX.N 14) Install boot vlock on partition detected at runtime N 15) Install mbr root disk .XXXN 16) Failure writing mbr, do this manually, hit return .XX.N 17) make that partition active? == Right. This is obviously a rather important package, which *cannot* fail, plus is is very dependant on the actual state of the system. As such, the best you'll be able to do is allow a few questions to be pre-asked, and defer the remainder to the appropriate maintainer script. (BTW, I'm ccing this to Wichert and AJ as a sterling example of why debconf has to continue to support this type of thing in maintainer scripts. I think both of them don't want it to have this capability,[..] You'd be at least half right. To clarify a little: I want to be able to answer the questions up front, do the install and have it work. If I've made a mistake (like not put a file where I said I did maybe), I don't mind if it dies and leaves that package to be configured later or something. I don't want it to pause and leave the rest of the system unconfigured, though. This is just for my system, I don't really care that much how it works for other people. If we go through the `N' questions above, we have: .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy .XXXN 16) Failure writing mbr, do this manually, hit return ...failure cases, which I want to address as late as possible, rather than as soon as possible. (The realplayer question is mainly a failure question too, iirc) .XXXN5) Insert floppy, hit return .XX.?4) do I need to format the floppy? .XXXN8) you have floppy, hit return when ready ...questions needing a temporary change in hardware. I'd answer no, I don't want to have a floppy initially, or perhaps want to run /usr/lib/kernel-2.2.17/make-floppy or something after my install's completed. .XX.N 14) Install boot block on partition detected at runtime You can detect stuff at runtime from within the .config too; you should be able to this before the package is actually installed. At worst, you can say no, don't try to detect it and annoy me later: this is what it should be. okay? trust me N 15) Install mbr root disk .XX.N 17) make that partition active? And hence you should be able to ask these beforehand too, I think. Basically, I'd like to be able to insist that I'm *never* asked a question as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg just get on with installing everything else, although it probably won't at the moment) than get asked a question. One way of dealing with this might be to have a debconf question, debconf/interactive-postinst. If this is answered no, then attempts to ask questions from the postinst (rather than the config) should simply fail with an error return. In .config's, logic somewhat like: db_input kernel-image-blah/make-a-boot-floppy if kernel-image-blah/make-a-boot-floppy = yes; then if debconf/interactive-postinst = no; then db_input kernel-image-blah/cant-make-a-boot-floppy db_set kernel-image-blah/make-a-boot-floppy no fi fi should be used, I suppose. Or perhaps: if debconf/interactive-postinst = yes; then db_input kernel-image-blah/make-a-boot-floppy else db_input kernel-image-blah/cant-make-a-boot-floppy db_set kernel-image-blah/make-a-boot-floppy no fi would
Re: policy changes toward Non-Interactive installation
Anthony Towns wrote: X...Y1) Ask to remove /System.map files .X Y2) ask to prepare a boot floppy XXX.Y3) ask which floppy drive to use .XX.?4) do I need to format the floppy? .XXXN5) Insert floppy, hit return .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN8) you have floppy, hit return when ready .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy XX..Y 11) if conf exists ask if we should run $loader with old config XXX.Y 12)Or else ask if a new $loader config .XX.Y 13) Or else ask if loader needed at all .XX.N 14) Install boot vlock on partition detected at runtime N 15) Install mbr root disk .XXXN 16) Failure writing mbr, do this manually, hit return .XX.N 17) make that partition active? You'd be at least half right. To clarify a little: I want to be able to answer the questions up front, do the install and have it work. If I've made a mistake (like not put a file where I said I did maybe), I don't mind if it dies and leaves that package to be configured later or something. I don't want it to pause and leave the rest of the system unconfigured, though. Right, and I think that's what Manoj is illistrating above. His Y's and N's seem to mostly make sense. ...failure cases, which I want to address as late as possible, rather than as soon as possible. (The realplayer question is mainly a failure question too, iirc) Yes, iirc it was (it's gone now, I think I was able to move the failure check robustly up to the config script). Basically, I'd like to be able to insist that I'm *never* asked a question as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg just get on with installing everything else, although it probably won't at the moment) than get asked a question. That's do-able. Once debconf knows to run postinsts in full noninteractive mode, critical questions that are thus not asked at all, and which do not have their return code caught, will simply cause the postinst to terminate with a nonzero return code. (I think this is better than making _all_ questions terminate it, which is not doable anyway, and also because if a postinst asks a priority low question, say, then that is by definition a question that the noninteractive mode can supply a reasonable answer to.) I'll be happy to implement a debconf/non-interactive-foo (should apply to all maintainer scripts save config, not just postinst, so I need a better name), if people think it will be generally useful. However, I presonally feel your specific case of the floppy prompting would be better served by: a) Making the question of low priority. or b) Making the question be asked only once, and this value used by all future kernel packges you install. Or adding a question, do you ever want to make a boot floppy? Especially b. -- see shy jo
