Hi, my starting point is:
1. /bin/sh can be a symbolic link to any shell. 2. The reasons to alter the symbolic link are legitimate. The rationale is: we do not want to cut off legitimate needs (even if we might not know them). The user consequently must have the freedom, to have /bin/sh as a symbolic link to whatever shell he wants. This often works fine. Many maintainers predict the choice of their users correctly, so that the majority of installation procedures run without any problems. We now care for the problems. The only real problem I can see is a maintainer, a) who does not want to require a specific shell, but b) wants to make sure, that all the scripts in his package work. Even this is legitimate in my opinion, even if I can imagine limits for this scenario. Instead of solving this problem by a revised policy, I propose a new package standardshell with the following functionality: the package manages a selected set of shells, which are considered to have a whatever standard functionality. The semantic is: if this package is installed, I can safely assume in /bin/sh a shell with standard functionality. The standard functionality is published in the docs of the package. If there is a problem, I can file a bug report to the standard shell package. If I am unsure about a possible functionality, I consult the documents of the package. Me as a maintainer can rely on this. The user hereby has the following grades of freedom : i) he can choose to not install the standardshell package. In this case, he is free to modify /bin/shell without restrictions. He must accept on the other hand, that packages, which require the standardshell, will refuse to install. In this way underlying conflicts show up. ii) The user can install the standardshell package. In this case he is restricted to the selected set of shells, the standardshell offers. Packages with standardshell requirements are sure on the other hand, that the functionality is in place because of the installed standardshell package. Could that work ? Regards M.Beier -- ------------------------------- Matthias Beier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
