On Thu, Jul 23 2009, Frans Pop wrote:
> Manoj Srivastava wrote:
>> I think we can engineer a system where Debian suggests various
>> shells as the default shell, and the user selects one. And only the
>> selected default shell is one that can't be removed from the system.
>
> Debian Installer could in theory support this by having a default shell
> (varying per-architecture even). It could also prompt the user for which
> shell to use in expert mode.
>
> The main challenge for installations would be that the default shell is
> installed by debootstrap, so that would need to be extended with a
> parameter to select a shell.
I can see a parameter for debootstrap; with perhaps the same
builtin default that d-i uses for the arch. The other way is to let
package priorities resolve this, more on this below.
> Problem is package priorities: can you have (pseudo) package that is
> priority required which is provided by packages that are all priority
> optional (which the shells would have to be to avoid them being
> installed automatically by debootstrap or the standard task)? And
> that would also mean that no packages of prio standard or higher can
> be allowed to depend on a specific shell (as policy would make that
> shell package get the same priority).
Perhaps a high priority, or even an currently essential package
depends on the (pseudo) package which is provided by packages with
POSIX shells that meet policy requirements for /bin/sh.
This way, in order to fulfill the requirements of the essential
package, we shall need at least one shell; which one it is will flow
out of libapt. If the user selects a shell, or d-i does, the
requirement is met.
This will allow people to install more than one candidate, but
prevent them from removing the last candidate.
The tricky part, though, is managing the symlink.
> In addition all shells supported as defaults would need to be included
> on CD images. And the selected shell would of course have to be set as
Well, the set of packages included can serve as the initial
selection offered to the user, though it does not need to be the
complete set of policy compliant POSIX shells, I would think that the
release and D-I teams will make the decision as to what does or does
make the cut.
> the default for new users. Debootstrap would still need a sane
> default in case no shell is set through a parameter or if the selected
> shell is not available for some reason.
Well, if the psuedo package posix-shell is a requirement of an
essential package, do you still need such hard coded fall backs?
> For switching the default shell on an installed system, something (a
> prerm script shared between shell packages?) would need to check for
> the shell being removed whether there are users who have it as their
> default shell and what the default shell for new users is, and fail if
> the shell is still in use. I also feel that this is a case where
> showing a debconf dialog warning about possible consequences is
> appropriate.
Well, it is very tricky, espescially on multi-user systems --
since you never know what might fail if /bin/sh changes under local
scripts. But I guess the sysadmin can just say no to changes, in that
case. But most certainly there should be no action taken unless the
user has given the go-ahead.
manoj
signing with his new openpgp card
--
Bell Labs Unix -- Reach out and grep someone.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Attachment:
pgpEK3AF0ejet.pgp
Description: PGP signature