Re: Switching /bin/sh to dash without dash essential
Frans Pop <elendil@planet.nl> writes:
> 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.
Default to dash (as that seems to be prefered, or why do we have that
conversation at all?). In expert mode create a list of anything
providing posix-sh and let the user pick one.
> 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.
Actualy the installation would be automatic through an essential
"the-shell" package that (pre-)depends on default-posix-sh |
posix-sh. Essential so it can not be removed so that its dependency
keeps at least one /bin/sh installed.
The only really new and tricky thing would be that (c)debootstrap
would need to create the /bin/sh link after unpacking. Packages can
not contain that link and maintainer scripts aren't run in debootstrap
at first. Or it needs to run the maintainer scripts of at least one
posix-sh first and that script must not use /bin/sh (but can use
/bin/itself).
> 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)?
Isn't that exactly the mawk/gawk situation?
Essential/Required/Standard packages need awk but there is still a
choice which of the two to use. Only now we have exactly one package
(the-shell) that depends on posix-sh.
> 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).
I think that is too strong. bash should still be standard I think. The
goal was to make it not essential so it can be removed on embedded
systems, right? On such systems you would have to have anything
(installed) depend on bash but that is their problem. It would be nice
to have nothing standard or higher depend on a specific shell but I
would not start with making that a MUST.
> 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 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.
Only one posix-sh MUST be included. Just like kernels. Everything else
will be solved by dependencies. If a shell is selected then the
the-shell package willhave its depends fullfilled already, otherwise
one will be picked to fullfill it.
I don't think including every shell on the install medium is such high
priority. After all the design here is so that one can later change
the shell too. The shells should probably be on dvd1 but having only
the major candidates on the netinst image is perfectly fine.
> 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.
That is somewhat unrelated to the issue. You can already install any
!bash shell, make it the default for some user and then purge
it. Nothing to do with the shell being /bin/sh.
> Plenty of challenges...
>
> Cheers,
> FJP
MfG
Goswin
Reply to: