Re: Switching /bin/sh to dash without dash essential
Steve Langasek wrote: On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote: You're correct of course. If we want to go this way there should be two questions: one for the system shell to use and one for the default user shell, each with per-arch defaults. Do you really think that the latter warrants a question? Admins can set their own policies by wrapping adduser; derivers can set their own policies by modifying the adduser package. I'm not sure. I merely wanted to explore the options. But it does seem to me that the ability to select the system and user shell at installation time could be a nice feature for advanced users. I think that quite a few sites may want to stick with the single shell to avoid the risk of incompatibilities option that Manoj put forward. So selecting the system shell makes a lot of sense to me. I'm less sure whether the option of selecting the user shell is really needed as well, but if you do one then supporting the other as well is probably not all that much more work. From the discussion there seem to be three groups: - embedded: want to have only a single, lightweight shell installed for both system and users; - generic: want a fast system shell, but a more powerful shell for users; - conservative: don't want to run any risk with script incompatibilities and thus want to have the same, powerful shell for system and users. It seems to me all three are valid. Has anyone actually said in this thread that I'm developing an embedded system and I want the user shell to be dash? dash is a terrible user shell, after all. No, they have said I'm developing an embedded system and I only want dash installed. Whether that means the system has no users (or at least shell using ones) at all, or they'll use dash for the (probably limited) tasks, or they want to use some other shell as user shell I don't know. But in all three cases they want the option of not installing bash as user shell, which could be facilitated by a question. Otherwise, yes, these are all valid cases, but I don't think that's really been a point of contention here; the only contention has been: - which configuration is the default? - do we need to generalize beyond dash and bash to meet these use cases? That is indeed the discussion. My thoughts regarding D-I and debootstrap are IMO an extention of the first question: how flexible do we want the default to be. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote: You're correct of course. If we want to go this way there should be two questions: one for the system shell to use and one for the default user shell, each with per-arch defaults. Do you really think that the latter warrants a question? Admins can set their own policies by wrapping adduser; derivers can set their own policies by modifying the adduser package. From the discussion there seem to be three groups: - embedded: want to have only a single, lightweight shell installed for both system and users; - generic: want a fast system shell, but a more powerful shell for users; - conservative: don't want to run any risk with script incompatibilities and thus want to have the same, powerful shell for system and users. It seems to me all three are valid. Has anyone actually said in this thread that I'm developing an embedded system and I want the user shell to be dash? dash is a terrible user shell, after all. Otherwise, yes, these are all valid cases, but I don't think that's really been a point of contention here; the only contention has been: - which configuration is the default? - do we need to generalize beyond dash and bash to meet these use cases? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Philipp Kern tr...@philkern.de writes: On 2009-07-25, Goswin von Brederlow goswin-...@web.de wrote: The existing dash package uses dpkg-divert, which is unsuitable on a larger scale (larger than the one dash package). And to have bash removable dash has to force itself as /bin/sh. So there goes even that little choice. What alternative do you speak off where the user will have a choice of what is /bin/sh? I don't see us supporting anything else than dash and bash for /bin/sh for squeeze. So the current solution is acceptable. You can try to prove me wrong, of course. But someone would need to collect the falling out pieces when /bin/sh is switched to something they want to see supported (and commit to that). But can you see that some other option would be possible in the future? That someone might want to try something else as /bin/sh and start fixing the bugs that causes? I do feel that that is a possibility and we should not go from being locked into bash being essential and /bin/sh to being locked into dash being essential and /bin/sh. That is what it is all about. zsh is certainly not suitable for /bin/sh, sorry. Kind regards, Philipp Kern PS: I do use zsh as user shell, though and would like to thank for his work on that. ;-) Never said it would. Doubt it will be in the near future. Far more likely would be posh or busybox. But you never know. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Goswin von Brederlow goswin-...@web.de (24/07/2009): Give me the freedom to choose. It looks like we just reached the “Linux is about choice” Goswin point. Mraw, KiBi. signature.asc Description: Digital signature
Re: Switching /bin/sh to dash without dash essential
Hi Sam, on Thu, Jul 23, 2009 at 16:53 -0400, you wrote: Siggy == Siggy Brentrup deb...@psycho.i21k.de writes: [snipping nonsense and reply] My sincere apologies for that nonsense, my only excuse is that I was overtired and I'm quite concerned about this issue not being solved in 5 years I've be away from d-d. humbly-yours Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Re: Switching /bin/sh to dash without dash essential
Philipp Kern wrote: On 2009-07-23, Frans Pop elen...@planet.nl wrote: 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. Strike the of course. If I want my users to have zsh as a default that's different from the question where I want to point my /bin/sh to. You're correct of course. If we want to go this way there should be two questions: one for the system shell to use and one for the default user shell, each with per-arch defaults. From the discussion there seem to be three groups: - embedded: want to have only a single, lightweight shell installed for both system and users; - generic: want a fast system shell, but a more powerful shell for users; - conservative: don't want to run any risk with script incompatibilities and thus want to have the same, powerful shell for system and users. It seems to me all three are valid. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Frans Pop elen...@planet.nl writes: Philipp Kern wrote: On 2009-07-23, Frans Pop elen...@planet.nl wrote: 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. Strike the of course. If I want my users to have zsh as a default that's different from the question where I want to point my /bin/sh to. You're correct of course. If we want to go this way there should be two questions: one for the system shell to use and one for the default user shell, each with per-arch defaults. From the discussion there seem to be three groups: - embedded: want to have only a single, lightweight shell installed for both system and users; - generic: want a fast system shell, but a more powerful shell for users; - conservative: don't want to run any risk with script incompatibilities and thus want to have the same, powerful shell for system and users. It seems to me all three are valid. Hear hear. That sums it up nicely. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Sun, Jul 26 2009, Frans Pop wrote: You're correct of course. If we want to go this way there should be two questions: one for the system shell to use and one for the default user shell, each with per-arch defaults. From the discussion there seem to be three groups: - embedded: want to have only a single, lightweight shell installed for both system and users; - generic: want a fast system shell, but a more powerful shell for users; - conservative: don't want to run any risk with script incompatibilities and thus want to have the same, powerful shell for system and users. It seems to me all three are valid. +1. Though I would say that there are other reasons than risk aversion for the last preference, for example having a heterogeneous development environment where the other Linux boxes all use bash as bin/sh manoj -- Better to be nouveau than never to have been riche at all. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote: Why would you think the one transition would be helpfull in the second or that there would be less breakage in the second if we do the first one first? I would rather say you are doubling the problems and breakages as the two are completly different mechanisms. Making the shell selectable means more code than hardcoding a single string. More code means more bugs. Since a bug in this case can result in an unbootable system, doing things one step at a time so you only have to look for bugs in one component at a time makes perfect sense IMHO. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote: On Fri, Jul 24 2009, Steve Langasek wrote: On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? Why would you set your default shell to posh? It's only marginally smaller than dash, and my understanding is that it's slower. It's more minimal from a policy perspective, but I don't see that this is relevant for a live Debian system. What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? It allows all the #!/bin/sh scripts that us zsh-isms to run. They can already be run under #!/bin/zsh. Why would we want to tie our hands even further as a distribution by putting ourselves in the position of having end users deploying /bin/sh scripts that require zsh, *in addition* to the end users who already deploy /bin/sh scripts that require bash? And I think it has yet to be demonstrated that it's actually useful to support all these other possible values of /bin/sh. Without a concrete reason why these configurations should be supported, generalizing the implementation is needless overhead. Demonstrated to whom? You see, viability of alternatives has to be demonstrated to the decision maker. My contention is that the Vendor ought not to be the decision maker here, that the quality of implementation of the OS improves if the system owner or custodian has the ability to make that determination. I propose to turn /usr/bin/make into an alternative so that Debian is not robbing users of the ability to decide they want it to point to pmake. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 09:15:43PM +0200, Goswin von Brederlow wrote: And what if my posh is compiled against uclibc? You never know. For embedded systems that is not too far fetched. The embedded system developers could just as easily build dash against uclibc instead of posh. Stop being difficult. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: shells and posix compliance [was Re: Switching /bin/sh to dash without dash essential]
Clint Adams wrote: [not replying off-list because that seems counterproductive and arrogant] On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote: Actually, if it's invoked as /bin/sh, it is supposed to be Bourne-compatible. That's my experience with the current version: Not much effort is put into strict POSIX compliance, though people certainly do complain about it[1]. I don't know what other versions do. I'm working on finding bugs with zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh (POSIX, XSI, or Debian) testsuite, please let me know off-list. I'd certainly welcome improvements to the posh testsuite to that end. Run the harness with category 'debian' or 'posix' depending on which standard you're going for. BTW Linux is not POSIX. Linux (LSB) has few incompatible rules. Check the join working document austin (POSIX) and LSB: http://www.opengroup.org/platform/single_unix_specification/doc.tpl?CALLER=index.tplgdid=13450 Personal opinion: it seems that linux will do some changes to be more posix compatible, but for most of incompatibilities (IMHO) POSIX will change toward linux. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-25 09:53:06 +0200, Steve Langasek wrote: On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote: On Fri, Jul 24 2009, Steve Langasek wrote: What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? It allows all the #!/bin/sh scripts that us zsh-isms to run. They can already be run under #!/bin/zsh. Why would we want to tie our hands even further as a distribution by putting ourselves in the position of having end users deploying /bin/sh scripts that require zsh, *in addition* to the end users who already deploy /bin/sh scripts that require bash? I don't know what Manoj had in mind exactly, but he hasn't said that zsh would be required. Think about something like that: #!/bin/sh if test -n $ZSH_VERSION; then foo=$HOME:t else foo=... - slower version for generic POSIX shells fi -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Goswin von Brederlow wrote: But that should be a choice. Not forced upon the user. As Manoj has said now a few times, many things will break for users even if all of Debian is dash fixed. By making /bin/sh choosable everybody wins. Who said anything about not offering the user to choose what /bin/sh points to? Nobody. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Gabor Gombas gomb...@sztaki.hu writes: On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote: Why would you think the one transition would be helpfull in the second or that there would be less breakage in the second if we do the first one first? I would rather say you are doubling the problems and breakages as the two are completly different mechanisms. Making the shell selectable means more code than hardcoding a single string. More code means more bugs. Since a bug in this case can result in an unbootable system, doing things one step at a time so you only have to look for bugs in one component at a time makes perfect sense IMHO. Gabor But having the string hardcoded to /bin/bash or to /bin/dash makes absolutely no difference later when it comes to making it selectable. You get exactly the same bugs then and you also get the bugs now for changing the hardcoded string. It is not doing things a step at a time. It is taking one step to the right and then taking a step forward. Steping to the right first doesn't move you forward at all. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Raphael Geissert atomo64+deb...@gmail.com writes: Goswin von Brederlow wrote: But that should be a choice. Not forced upon the user. As Manoj has said now a few times, many things will break for users even if all of Debian is dash fixed. By making /bin/sh choosable everybody wins. Who said anything about not offering the user to choose what /bin/sh points to? Nobody. Cheers, Raphael Geissert Then where is that choice? How will it be done? The proposal has shown one way of doing it. The existing dash package uses dpkg-divert, which is unsuitable on a larger scale (larger than the one dash package). And to have bash removable dash has to force itself as /bin/sh. So there goes even that little choice. What alternative do you speak off where the user will have a choice of what is /bin/sh? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-25, Goswin von Brederlow goswin-...@web.de wrote: The existing dash package uses dpkg-divert, which is unsuitable on a larger scale (larger than the one dash package). And to have bash removable dash has to force itself as /bin/sh. So there goes even that little choice. What alternative do you speak off where the user will have a choice of what is /bin/sh? I don't see us supporting anything else than dash and bash for /bin/sh for squeeze. So the current solution is acceptable. You can try to prove me wrong, of course. But someone would need to collect the falling out pieces when /bin/sh is switched to something they want to see supported (and commit to that). zsh is certainly not suitable for /bin/sh, sorry. Kind regards, Philipp Kern PS: I do use zsh as user shell, though and would like to thank for his work on that. ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Frans Pop elen...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Goswin von Brederlow goswin-...@web.de writes: Frans Pop elen...@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?). You seem to be suggesting that having ‘dash’ as the default interactive login shell is preferred. I don't think that's true. If I understand correctly, the proposal is very much *not* about making ‘dash’ the default interactive login shell for the installed system, but instead about making ‘dash’ the default implementation of ‘/bin/sh’. -- \ “If you see an animal and you can't tell if it's a skunk or a | `\ cat, here's a good saying to help: ‘Black and white, stinks all | _o__) right. Tabby-colored, likes a fella.’” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Thu, Jul 23, 2009 at 04:10:54PM -0500, Manoj Srivastava wrote: We want everyone to use dash by default. Who is we? Why is the sysadmin not the one making the decision? Why is the Vendor making this decision for the user? Because there's no reason for an end user to care about which shell /bin/sh points to. If they care, it's because they're expecting to use it for something beyond what Policy guarantees it to do; that's not something we should encourage, they should invoke the shell directly if they want to use other features. If someone does not want to use the default, they are free to do so, but the default system shell is supposed to always be on the system. Why? Is there a technical reason, or because you say so? Frankly, if a user is happy with bash, they need bash anyway cause they have users that use it as an interactive shell, adding dash is pure bloat. They might not care for the 4 seconds it saves them on boot, since they rarely boot. Pure bloat? $ dpkg -I d/dash/dash_0.5.5.1-2.1_i386.deb |grep Size Installed-Size: 216 $ That's scarcely more than the size *increase* in util-linux (an essential package) between lenny and squeeze: $ dpkg -I u/util-linux/util-linux_2.13.1.1-1_i386.deb |grep Size Installed-Size: 1624 $ dpkg -I u/util-linux/util-linux_2.15.1~rc1-1_i386.deb |grep Size Installed-Size: 1736 $ And in an embedded context with /usr/share/doc removed, the only impact is /bin/dash, which weighs in at a mere 84k. On whose behalf are you splitting these hairs, exactly? 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. I think we can engineer lots of things we don't need, this being just one of them. If the goal is to make *bash* removable, then I can understand why that would be helpful to some people since it's the heavier shell by far. None of what you're talking about in this subthread actually advances that goal, however. The blocker for removing bash is that today, packages invoking /bin/bash are not required by Policy to depend on it. And if they did, we might find that there are Priority: required packages using it, which there's no policy against, making the exercise more or less pointless. Oh yeah - libpam0g is one, and libpam0g is transitively essential. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Ben Finney ben+deb...@benfinney.id.au writes: Goswin von Brederlow goswin-...@web.de writes: Frans Pop elen...@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?). You seem to be suggesting that having âdashâ as the default interactive login shell is preferred. I don't think that's true. If I understand correctly, the proposal is very much *not* about making âdashâ the default interactive login shell for the installed system, but instead about making âdashâ the default implementation of â/bin/shâ. We are only talking about /bin/sh here. Everything else is a different matter and unrelated. And /bin/sh has nothing to do with the default interactive login shell (on new systems). MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Siggy Brentrup wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. These discussions are extremely long standing :) The move away from bash has been aimed at long before I vanished from the project in 2004. I'm really upset that 5 years are not enough to accomplish the move. So how many of the bashism bugs did you fix? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek vor...@debian.org writes: On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. What about Manojs argument of having user scripts that (falsely) use bashism and #!/bin/sh or user accounts with /bin/sh as login shell? The proposed solution would allow the admin to choose what shell is /bin/sh and even more so would keep bash as /bin/sh on existing systems unless as different /bin/sh is specificaly configured. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Thu, Jul 23, 2009 at 04:04:03PM -0500, Manoj Srivastava wrote: If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. Source? Policy does not even ban bashims for maintainer scripts. Policy 10.4 says: If a shell script requires non-SUSv3 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., `#!/bin/bash') and the package must depend on the package providing the shell (unless the shell package is marked Essential, as in the case of `bash'). So bashisms are allowed in maintainer scripts only if they invoke /bin/bash as the interpreter. Or do you mean something else by ban, here? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 12:31:09PM +0200, Goswin von Brederlow wrote: Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. What about Manojs argument of having user scripts that (falsely) use bashism and #!/bin/sh or user accounts with /bin/sh as login shell? The proposed solution would allow the admin to choose what shell is /bin/sh and even more so would keep bash as /bin/sh on existing systems unless as different /bin/sh is specificaly configured. Permitting the user to choose where /bin/sh points is orthogonal to whether dash is Essential. There's already support for user configuration of the /bin/sh link, and my understanding is that the proposal actually on the table doesn't change that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek wrote: On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. +1 from me. Making things more complicated when there is no need to do so is a waste of time. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek wrote: On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. I'm not so sure on the long run: - maybe a truly posix-like tiny shell will emerge. - We need to solve in next 5 to 10 years the echo -n problem. IIRC there is a join group POSIX-LSB to solve this and other Linux incompatibility problem. - what make special dash? I was using when it was named ash. In the future maybe it will change the name, removing the Debian d. Maybe a super cool tiny and very fast shell will emerge and supercede dash. What will we do? Need to support an essential third shell implementation? So want to leave such door open. Just provide the interface (a POSIX like shell), not a name of an implementation. PS: I really want to have dash as default shell. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve == Steve Langasek vor...@debian.org writes: Steve On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Steve Yes, that's definitely my position. OK, I'm fine with that. I jumped into this mess because several people asserted that we were making dash essential because it was technically required. As best I can tell that is false. It seems like there was a lot of not listening going on, and a lot of throwing around assertions about what is and is not possible without actually any attention to the accuracy of those assertions. That makes me grumpy and so I got involved. I'm happy with the answer of making dash essential is easier than not doing so and we have not seen a compelling reason to do something else. Steve From what I can see, Steve engineering a solution where dash doesn't need to be Steve essential isn't worth *any* effort, because IMHO, so far Steve the arguments for being able to remove dash from the system Steve appear entirely contrived. I think you're being unfair here. There are arguments about technical cleanlyness and design esthetics that seem reasonable. I don't see that these arguments appear contrived. I'm happy to agree with you though that these arguments don't justify the work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24 2009, Steve Langasek wrote: On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. manoj -- We learn from history that we learn nothing from history. George Bernard Shaw Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24 2009, Steve Langasek wrote: On Thu, Jul 23, 2009 at 04:10:54PM -0500, Manoj Srivastava wrote: We want everyone to use dash by default. Who is we? Why is the sysadmin not the one making the decision? Why is the Vendor making this decision for the user? Because there's no reason for an end user to care about which shell /bin/sh points to. If they care, it's because they're expecting to use it for This seems like a failure in imagination. I am an end user, and I certainly have reasons to care. At my last job, there were production machines that would have cared something beyond what Policy guarantees it to do; that's not something we should encourage, they should invoke the shell directly if they want to use other features. Whether or not we want to encourage behaviour that does not depend on a practice we have followed for 16 years is really besides the point: There is an isntalled base of user scripts out there _now_ since we have had /bin/sh pointing to bash, like forever. For new installations, this matters slightly less, though changing the default for a new install would make the machine behave differently from existing Debian machines in the environment, which is suboptimal from the user's perspective. If someone does not want to use the default, they are free to do so, but the default system shell is supposed to always be on the system. Why? Is there a technical reason, or because you say so? Frankly, if a user is happy with bash, they need bash anyway cause they have users that use it as an interactive shell, adding dash is pure bloat. They might not care for the 4 seconds it saves them on boot, since they rarely boot. Pure bloat? $ dpkg -I d/dash/dash_0.5.5.1-2.1_i386.deb |grep Size Installed-Size: 216 $ It is still bloat. Not much of a bloat, you might argue, but bloat it is. You think Debian can decide when bloat is too much, or not, but I think Debian would have a better quality of implementation were we to let the end user decide when bloat is too much, if we can. On whose behalf are you splitting these hairs, exactly? For the most important user in the world, of course: Judy, who runs debian on her XO. 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. I think we can engineer lots of things we don't need, this being just one of them. Frankly, I think that moving /bin/sh is another thing we don't need, but thankfully the project does not run on personal opinion, nor do we have a dictator for life making us do things one way. If the goal is to make *bash* removable, then I can understand why that would be helpful to some people since it's the heavier shell by far. Right. None of what you're talking about in this subthread actually advances that goal, however. The blocker for removing bash is that Frankly, I think you are overlooking a whole lot of things. The frst thing you need to do is to not just make bash removable, you need to determine of this particular user _wants_ it too. You can't just have a limited set of scenarios (people want lean /bin/sh) and not (people want all machines in their environment behaving closer to each other). today, packages invoking /bin/bash are not required by Policy to depend on it. And if they did, we might find that there are Priority: required packages using it, which there's no policy against, making the exercise more or less pointless. Oh yeah - libpam0g is one, and libpam0g is transitively essential. Again the tunnel vision on packages -- there are users with installed bases too, which every one seems to just forget. The idea I am espousing is that we need to come up with not just replace bash with dash, we need to ask the user if they want to change the default shell, and whether the new default shell should be dash. manoj -- Given its constituency, the only thing I expect to be open about [the Open Software Foundation] is its mouth. -- John Gilmore Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24 2009, Steve Langasek wrote: On Thu, Jul 23, 2009 at 04:04:03PM -0500, Manoj Srivastava wrote: If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. Source? Policy does not even ban bashims for maintainer scripts. Policy 10.4 says: If a shell script requires non-SUSv3 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., `#!/bin/bash') and the package must depend on the package providing the shell (unless the shell package is marked Essential, as in the case of `bash'). That is not a ban, is it? So bashisms are allowed in maintainer scripts only if they invoke /bin/bash as the interpreter. Sounds like a recipe to allow using bash scripts. Or do you mean something else by ban, here? So, saying that people should use dpkg-shlibs, by invoking it just so, is banning dpkg-shlibs? My head spins. manoj -- Most people would rather die than think; in fact, they do so. -Bertrand Russell Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? Why would you set your default shell to posh? It's only marginally smaller than dash, and my understanding is that it's slower. It's more minimal from a policy perspective, but I don't see that this is relevant for a live Debian system. What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. And I think it has yet to be demonstrated that it's actually useful to support all these other possible values of /bin/sh. Without a concrete reason why these configurations should be supported, generalizing the implementation is needless overhead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Hi, On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? posh (or strict POSIX in general) is simply not practical, and zsh is even more bloated than bash. But this was discussed to death... I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. And a possible response to such an objection that the bash-dash transition is difficult enough. Do this specific transition first, and revisit the generalization only after the lessons from the bash-dash transition have been learned. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek vor...@debian.org writes: What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? zsh has also historically been fairly buggy in corner cases as /bin/sh and requires explicit commands to make it Bourne-compatible. Autoconf has had to add a bunch of workarounds for zsh as sh that I'm sure most of our shell scripts don't have. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote: zsh has also historically been fairly buggy in corner cases as /bin/sh and requires explicit commands to make it Bourne-compatible. Autoconf has had to add a bunch of workarounds for zsh as sh that I'm sure most of our shell scripts don't have. Actually, if it's invoked as /bin/sh, it is supposed to be Bourne-compatible. That's my experience with the current version: lakeview ok % emulate; /bin/sh -c emulate zsh sh I don't know what other versions do. I'm working on finding bugs with zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh (POSIX, XSI, or Debian) testsuite, please let me know off-list. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Switching /bin/sh to dash without dash essential
On Fri, Jul 24 2009, Steve Langasek wrote: On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? Why would you set your default shell to posh? It's only marginally smaller than dash, and my understanding is that it's slower. It's more minimal from a policy perspective, but I don't see that this is relevant for a live Debian system. What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? It allows all the #!/bin/sh scripts that us zsh-isms to run. I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. And I think it has yet to be demonstrated that it's actually useful to support all these other possible values of /bin/sh. Without a concrete reason why these configurations should be supported, generalizing the implementation is needless overhead. Demonstrated to whom? You see, viability of alternatives has to be demonstrated to the decision maker. My contention is that the Vendor ought not to be the decision maker here, that the quality of implementation of the OS improves if the system owner or custodian has the ability to make that determination. In which case, proving which shell is better is taken out of the equation, and what we have to do is support the custodian choice. manoj -- The whole earth is in jail and we're plotting this incredible jailbreak. Wavy Gravy Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Gabor Gombas wrote: Hi, On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? posh (or strict POSIX in general) is simply not practical, and zsh is even more bloated than bash. But this was discussed to death... I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. And a possible response to such an objection that the bash-dash transition is difficult enough. Do this specific transition first, and revisit the generalization only after the lessons from the bash-dash transition have been learned. When a program will gain the essential flag, it will be forever. So yet will need to support one shell bash. tomorrow two shells (bash and dash). In future could we support three shells? Note: also when upstream will stop supporting the program (e.g. new POSIX version, etc). The discussion is about essential (check the subject), not really what shell will be the default on tomorrow and future debian systems. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek vor...@debian.org writes: On Fri, Jul 24, 2009 at 12:31:09PM +0200, Goswin von Brederlow wrote: Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. Yes, that's definitely my position. From what I can see, engineering a solution where dash doesn't need to be essential isn't worth *any* effort, because IMHO, so far the arguments for being able to remove dash from the system appear entirely contrived. What about Manojs argument of having user scripts that (falsely) use bashism and #!/bin/sh or user accounts with /bin/sh as login shell? The proposed solution would allow the admin to choose what shell is /bin/sh and even more so would keep bash as /bin/sh on existing systems unless as different /bin/sh is specificaly configured. Permitting the user to choose where /bin/sh points is orthogonal to whether dash is Essential. There's already support for user configuration of the /bin/sh link, and my understanding is that the proposal actually on the table doesn't change that. Where is that support? The dpkg-divert in sid dash is not suitable on a larger scale. It is a verry limited solution. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek vor...@debian.org writes: On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? Why would you set your default shell to posh? It's only marginally smaller than dash, and my understanding is that it's slower. It's more minimal from a policy perspective, but I don't see that this is relevant for a live Debian system. Because I'm just in love with posh and dash sucks. Bah, stupid dash, give me my posh. :))) Give me the freedom to choose. What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? Plus the libaries dash depends on (if they differ from posh) and the larger memory footprint of having 2 different shells running. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Gabor Gombas gomb...@sztaki.hu writes: Hi, On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote: I think you are not going far enough. Why should I have dash on the system when my default shell is posh? or (gasp) zsh? posh (or strict POSIX in general) is simply not practical, and zsh is even more bloated than bash. But this was discussed to death... I think one of the objections here is that we ought to have a more generic approach that allows shells other than dash/bash to be the default shell, and that the vendor not make the choice. And a possible response to such an objection that the bash-dash transition is difficult enough. Do this specific transition first, and revisit the generalization only after the lessons from the bash-dash transition have been learned. Gabor Why would you think the one transition would be helpfull in the second or that there would be less breakage in the second if we do the first one first? I would rather say you are doubling the problems and breakages as the two are completly different mechanisms. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Manoj Srivastava sriva...@debian.org writes: On Fri, Jul 24 2009, Steve Langasek wrote: If the goal is to make *bash* removable, then I can understand why that would be helpful to some people since it's the heavier shell by far. Right. None of what you're talking about in this subthread actually advances that goal, however. The blocker for removing bash is that Frankly, I think you are overlooking a whole lot of things. The frst thing you need to do is to not just make bash removable, you need to determine of this particular user _wants_ it too. You can't just have a limited set of scenarios (people want lean /bin/sh) and not (people want all machines in their environment behaving closer to each other). I actualy would like to remove bash. Dash seems to be better as /bin/sh from what people say. And as interactive shell I use zsh. So why waste the space with an bloated bash? But that should be a choice. Not forced upon the user. As Manoj has said now a few times, many things will break for users even if all of Debian is dash fixed. By making /bin/sh choosable everybody wins. today, packages invoking /bin/bash are not required by Policy to depend on it. And if they did, we might find that there are Priority: required packages using it, which there's no policy against, making the exercise more or less pointless. Oh yeah - libpam0g is one, and libpam0g is transitively essential. Again the tunnel vision on packages -- there are users with installed bases too, which every one seems to just forget. The idea I am espousing is that we need to come up with not just replace bash with dash, we need to ask the user if they want to change the default shell, and whether the new default shell should be dash. manoj MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-24 15:49:15 +, brian m. carlson wrote: On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote: zsh has also historically been fairly buggy in corner cases as /bin/sh and requires explicit commands to make it Bourne-compatible. Autoconf has had to add a bunch of workarounds for zsh as sh that I'm sure most of our shell scripts don't have. Actually, if it's invoked as /bin/sh, it is supposed to be Bourne-compatible. I suppose that (both of) you mean POSIX-compatible (as there are differences between the traditional Bourne shell and POSIX shells). That's my experience with the current version: lakeview ok % emulate; /bin/sh -c emulate zsh sh I don't know what other versions do. I'm working on finding bugs with zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh (POSIX, XSI, or Debian) testsuite, please let me know off-list. I've also reported a number of zsh POSIX-compatibility bugs. There are still differences between shells concerning set -e [*], and AFAIK, POSIX hasn't been made clear yet. I wonder how this is dealt with in the switch from bash to dash for /bin/sh. [*] See http://www.in-ulm.de/~mascheck/various/set-e/ -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek vor...@debian.org writes: What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? [Goswin von Brederlow] Plus the libaries dash depends on (if they differ from posh) NEEDED libc.so.6 Oh well, guess we have a little less FUD now. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Peter Samuelson pe...@p12n.org writes: Steve Langasek vor...@debian.org writes: What's the advantage of having it be zsh? Is zsh faster than dash? Or is the only savings the elimination of the 84k dash binary from /bin? [Goswin von Brederlow] Plus the libaries dash depends on (if they differ from posh) NEEDED libc.so.6 Oh well, guess we have a little less FUD now. And what if my posh is compiled against uclibc? You never know. For embedded systems that is not too far fetched. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
shells and posix compliance [was Re: Switching /bin/sh to dash without dash essential]
[not replying off-list because that seems counterproductive and arrogant] On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote: Actually, if it's invoked as /bin/sh, it is supposed to be Bourne-compatible. That's my experience with the current version: Not much effort is put into strict POSIX compliance, though people certainly do complain about it[1]. I don't know what other versions do. I'm working on finding bugs with zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh (POSIX, XSI, or Debian) testsuite, please let me know off-list. I'd certainly welcome improvements to the posh testsuite to that end. Run the harness with category 'debian' or 'posix' depending on which standard you're going for. [1] http://www.zsh.org/mla/workers/2009/msg00881.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Switching /bin/sh to dash without dash essential
Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. Variations: 1) You could have a registration mechanism. My assumption is the set is small enough static is good 2) I assume that package operations cannot take place between calling the prerm script and actually removing the package. If that is false, you could make sure that you are changing the link to a configured shell I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. These discussions are extremely long standing :) The move away from bash has been aimed at long before I vanished from the project in 2004. I'm really upset that 5 years are not enough to accomplish the move. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? So you are complaining about a small package (installed size 224) becoming essential while forcing the embedded ppl to work around a monster (installed size 1236); numbers taken from my Ubuntu laptop where both are essential, I hope only for a limited period of time. Although preferring CLI over GUI I don't use both of them, I prefer zsh for my daily work but my #!/bin/sh scripts are always posixly correct. If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. Maybe posixly-correct-shell would be a better name. Summing up you suggest making a virtual package - however it's called - essential. While I think I grok your intentions, I doubt dpkg will follow, please read carefully: http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8 Variations: 1) You could have a registration mechanism. My assumption is the set is small enough static is good 2) I assume that package operations cannot take place between calling the prerm script and actually removing the package. If that is false, you could make sure that you are changing the link to a configured shell I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. See debian-policy cited above. looking-forward-for-posixly-correct-/bin/sh-ly yours Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Re: Switching /bin/sh to dash without dash essential
Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. We want everyone to use dash by default. If someone does not want to use the default, they are free to do so, but the default system shell is supposed to always be on the system. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. Not going to happen AFAICS. bash does not know about any for instance. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. Might be possible, but currently needs a lot of work and I don't see anyone interested to do that. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 'it' decides :-) 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. This seems ugly, I would rather go for a virtual package in that case similar to awk. I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. You do not want to give the possibility to remove /bin/sh from the system. Currently this is done by making the default system shell essential. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Siggy Brentrup deb...@psycho.i21k.de writes: On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. These discussions are extremely long standing :) The move away from bash has been aimed at long before I vanished from the project in 2004. I'm really upset that 5 years are not enough to accomplish the move. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? So you are complaining about a small package (installed size 224) becoming essential while forcing the embedded ppl to work around a monster (installed size 1236); numbers taken from my Ubuntu laptop where both are essential, I hope only for a limited period of time. Although preferring CLI over GUI I don't use both of them, I prefer zsh for my daily work but my #!/bin/sh scripts are always posixly correct. No, complaining about replacing shackles with handcuffs. If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. 1b) All /bin/sh shells must behave as if they where essential. They must work while being unconfigured and so on. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. Maybe posixly-correct-shell would be a better name. Summing up you suggest making a virtual package - however it's called - essential. While I think I grok your intentions, I doubt dpkg will follow, please read carefully: http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8 And what exactly do you mean? Nothing in there about virtual packages. Variations: 1) You could have a registration mechanism. My assumption is the set is small enough static is good 2) I assume that package operations cannot take place between calling the prerm script and actually removing the package. If that is false, you could make sure that you are changing the link to a configured shell It is false afaik. You can deconfigure any number of packages before starting to remove any of them. I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. See debian-policy cited above. looking-forward-for-posixly-correct-/bin/sh-ly yours Siggy Say you have only shell-1 installed to provide /bin/sh. The big question is if apt/aptitude/synaptic/.../dpkg will ever deconfigure or even uninstall shell-1 before it unpacks shell-2. Can the following sequence happens? deconfigure the-shell deconfigure shell-1 remove shell-1 unpack shell-2 configure shell-2 configure the-shell If this sequence ever happens then the system is without /bin/sh for a time. Not a good idea. I think the above is unlikely but can possibly happen and nothing in Depends or Pre-Depends can prevent it. But the prerm script could (should) fail if it can not find another /bin/sh provider to at least don't make the system unusable. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Luk == Luk Claes l...@debian.org writes: Luk We want everyone to use dash by default. If someone does not Luk want to use the default, they are free to do so, but the Luk default system shell is supposed to always be on the system. Why? I agree something should always provide /bin/sh. I do not understand why the default system shell should be on the system always. The only argument you've given that I understand is that no one wants to do the work necessary to guarantee that /bin/sh is always present and that the default system shell is not essential. If that's the answer, that's a perfectly fine answer, but *say that*, don't just make assertions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Thu, Jul 23 2009, Siggy Brentrup wrote: On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. These discussions are extremely long standing :) The move away from bash has been aimed at long before I vanished from the project in 2004. I'm really upset that 5 years are not enough to accomplish the move. I think because few proponents actually think through the impact on end user machines. There are more constituencies to Debian than just embedded users, and people write shell scritps on their own, and use it as cron jobs, helper functions (I use a couple to handle mailto: URI's in mozilla to fire up gnus). The impact on these systems bigger, since there are more of them, and embedded systems end users, who can definitely switch the link themselves. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? So you are complaining about a small package (installed size 224) becoming essential while forcing the embedded ppl to work around a monster (installed size 1236); numbers taken from my Ubuntu laptop where both are essential, I hope only for a limited period of time. Although preferring CLI over GUI I don't use both of them, I prefer zsh for my daily work but my #!/bin/sh scripts are always posixly correct. There is a traedeoff between an embedded system, and machines where user tools and cron jobs may break which If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. Source? Policy does not even ban bashims for maintainer scripts. manoj -- How can you be in two places at once when you're not anywhere at all? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Siggy == Siggy Brentrup deb...@psycho.i21k.de writes: 8 I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? Siggy So you are complaining about a small package (installed Siggy size 224) becoming essential while forcing the embedded ppl Siggy to work around a monster (installed size 1236); numbers Siggy taken from my Ubuntu laptop where both are essential, I Siggy hope only for a limited period of time. Hmm. I don't get any complaint about /bin/dash being the default system shell from my mail. Nor do you see me complaining about having /bin/sh scripts be posixly correct. If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. Siggy As long as /bin/sh refuses extensions to posix I agree with Siggy you, but bashism has been a cuss word for years before Siggy 2004. I don't understand how this has anything to do with anything I said. Siggy Maybe posixly-correct-shell would be a better name. Siggy Summing up you suggest making a virtual package - No. I suggest a package with no files but with pre-depends and the essential flag. I don't think a virtual package would work correctly at a technical level, although I'd be happy to be shown to be wrong. Siggy however Siggy it's called - essential. While I think I grok your Siggy intentions, I doubt dpkg will follow, please read Siggy carefully: Siggy http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8 Read that long ago and read that word for word just now. Can you help me understand what I'm missing? I don't see how what I'm proposing would violate that. I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. Siggy See debian-policy cited above. Again, please help me understand how what I propose would violate policy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Thu, Jul 23 2009, Luk Claes wrote: Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. We want everyone to use dash by default. Who is we? Why is the sysadmin not the one making the decision? Why is the Vendor making this decision for the user? If someone does not want to use the default, they are free to do so, but the default system shell is supposed to always be on the system. Why? Is there a technical reason, or because you say so? Frankly, if a user is happy with bash, they need bash anyway cause they have users that use it as an interactive shell, adding dash is pure bloat. They might not care for the 4 seconds it saves them on boot, since they rarely boot. 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. I kinda like the mawk/gawk solution, which has worked. Admittedly, /bin/sh is rather more critical to get right, but I think we have the ability to craft a solution to do so. manoj -- filibuster, n.: Throwing your wait around. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
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. 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). 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. 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. Plenty of challenges... Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-23, Manoj Srivastava sriva...@debian.org wrote: As long as /bin/sh refuses extensions to posix I agree with you, but bashism has been a cuss word for years before 2004. Source? Policy does not even ban bashims for maintainer scripts. Surely not, it just tells you to use bash in the shebang. You may wish to restrict your script to SUSv3 features plus the above set when possible so that it may use /bin/sh as its interpreter. If your script works with dash (originally called ash), it probably complies with the above requirements, but if you are in doubt, use /bin/bash. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-23, Frans Pop elen...@planet.nl wrote: 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. Strike the of course. If I want my users to have zsh as a default that's different from the question where I want to point my /bin/sh to. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
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 sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpWy04K5aKYp.pgp Description: PGP signature
