Hi Mark, Thank you for your response!
| > Before installing NIS, I had known that I needed to | > edit /etc/yp.conf for NIS to work; I intended to | | What makes you say that you need to edit /etc/yp.conf? Because our NIS servers are not on the same subnet as my machine. I think it's one of the purposes of yp.conf to specify NIS servers when they are on different subnets (that is, when they are not reachable by broadcast). Is that right? | > To solve this problem, I'd like to suggest that debconf | > ask either | | > 1) whether it should start ypbind now; or | > 2) whether NIS servers can be found by broadcasting | > (or something like that). | | > If the answer to the question is "no", debconf won't | > start ypbind but advise the user to start NIS after | > editing relevant configuration files. | | This sort of transitiory configuration is really not the sort of thing | that should go into debconf so I don't really think that this is an | appropriate solution. Given that the issue occurs only when installing | on a network where no existing server is available (which is a fairly | rare occurrence) and results in less than a minute of latency in the | installation I don't think the drawbacks of trying to force it through | debconf are worth it. On the contrary, I was sort of surprised that the configuration process tries to start ypbind before giving the user a chance of doing her own configurations. I don't know at all how common or rare the situation is where NIS servers are on different subnets. Regardless, I don't think any debconf process should fail when the user didn't give wrong parameters to it. (And I consider this particular case as a failure because ypbind gets stuck for 30 seconds or a minute and says "failed" in red letters.) In the case of the nis package, the user isn't given a chance of giving correct parameters to the debconf process. Regards, Ryo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
