Re: Switching /bin/sh to dash (part two)
On Fri, Jul 24, 2009 at 06:17:30PM +0200, Goswin von Brederlow wrote: Or we need to set explicitly use #!/bin/dash in umountall? [not so flexible solution, but IMHO enough good] If it needs dash then yes, set #!/bin/dash and Pre-Depend on dash. But in this case that really needs to be fixed to work with any posix shell. It's not the usual umountall uses features not in POSIX case but rather bash does lots of unneccessary things that in turn break umountall. umountall wants a shell that does not do any NSS lookups internally when it is not asked to. So it's bash that needs to be fixed to do a lot less when it is invoked as /bin/sh. 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 (part two)
On Fri, Jul 24, 2009 at 06:39:53PM +0200, Giacomo Catenazzi wrote: BTW it seems that all previous tries to remove the bug in bash failed. Actually it's not a bug in bash at all. The bug is the combined effect of how bash behaves and how the NSS functionality is implemented inside glibc. AFAIR fixing bash would make it incompatible with existing user scripts. So it would have (almost) all of the drawbacks of the bash-dash transition without none of the benefits. 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 (part two)
Gabor Gombas wrote: On Fri, Jul 24, 2009 at 06:39:53PM +0200, Giacomo Catenazzi wrote: BTW it seems that all previous tries to remove the bug in bash failed. Actually it's not a bug in bash at all. The bug is the combined effect of how bash behaves and how the NSS functionality is implemented inside glibc. AFAIR fixing bash would make it incompatible with existing user scripts. So it would have (almost) all of the drawbacks of the bash-dash transition without none of the benefits. Not necessarily, but also not easy to fix. bash could wait until the first nss use to connect to libc nss. This would also speed up bash for these users. Or telling bash (and shells in general) via some environment variable, that we are shutting down things. Not clean, but I think the init could provide some extra informations. 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 (part two)
Clint Adams sch...@debian.org wrote:
[...]
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst2009-07-24 09:00:38.0 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
# postinst based heavily on the postinst of libssl0.9.8, courtesy of
# Christoph Martin.
@@ -73,7 +73,7 @@
for service in $check; do
if [ -x `which invoke-rc.d 2/dev/null` ]; then
- idl=$(ls /etc/init.d/${service} 2 /dev/null | head -n 1)
+ idl=/etc/init.d/${service}
if [ -n $idl ] [ -x $idl ]; then
services=$service $services
else
Hello,
FWIW the $(...) construct is not a bashism.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, 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 (part two)
Giacomo Catenazzi wrote: Or telling bash (and shells in general) via some environment variable, that we are shutting down things. Not clean, but I think the init could provide some extra informations. There are a couple of variables begin set by the rc script, but I don't think bash should rely on variables to define behaviour in such a way. 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 (part two)
In article 2qrqj6-973@argenau.downhill.at.eu.org you wrote: if [ -n $idl ] [ -x $idl ]; then This misses quotes. Greetings Bernd -- 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 (part two)
[Bernd Eckenfels] if [ -n $idl ] [ -x $idl ]; then This misses quotes. So, how many unsafe characters do _you_ see in the following service names? apache2-common at bayonne cherokee courier-authdaemon cron cups dante-server diald dovecot-common exim exim4-base fcron fireflier-server freeradius gdm heartbeat heartbeat-2 hylafax-server iiimf-server inn2 kannel linesrv linesrv-mysql lsh-server muddleftpd netatalk nuauth partimage-server perdition pgpool popa3d postgresql-7.4 postgresql-8.1 postgresql-8.2 proftpd pure-ftpd pure-ftpd-ldap pure-ftpd-mysql pure-ftpd-postgresql racoon samba sasl2-bin sfs-server solid-pop3d squid squid3 tac-plus vsftpd wu-ftpd wzdftpd xrdp yardradius yaws -- Peter Samuelson | org-tld!p12n!peter | http://p12n.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 (part two)
On Thu, Jul 23, 2009 at 08:20:05PM -0500, Manoj Srivastava wrote: But well, one of the ideas is to avoid having such extra stuff deeply tied to the core system, i.e. essential. That's it? The time to try to reduce the set of Essential packages is to deny entry to new items (like dash), since once the package is essential, people (and not just package maintainers) come to rely on it. Our user base, in particular, has had 15+ years to rely on bash -- and there are loads of user scripts, support systems, cron jobs, third part packages -- that need bash. I think this is addressable by clearly documenting in Policy (where the handling of Essential packages is defined) that packages which invoke /bin/dash are required to depend on dash instead of relying on 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 (part two)
Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. One additional question: how can we setup dependencies, so that nis + mounted /usr/ needs explicitly dash as /bin/sh? [creating ugly dash-as-sh, bash-as-sh packages, who conflict each other and setup the symlink?] Or we need to set explicitly use #!/bin/dash in umountall? [not so flexible solution, but IMHO enough good] I think we should address this, because was one of the rationale for the switch. In long term we need to find a solution how to handle unsupported configuration in a flexible way (which will solve also lilo case: it works only with limited kernels and config) 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 (part two)
Manoj Srivastava wrote: On Wed, Jul 22 2009, Giacomo A. Catenazzi wrote: If we remove the essential flag, we have a nice feature: the packages who needs bash need to be documented (via Depends). Can you tell me how long did it take to move from /usr/doc to /usr/share/doc? I don't know real numbers, but: - it take long time: for this reason I want to start to discuss it now. I don't expect it for next release. We could recommend to document bash features. Policy doesn't forbid it - now we are braver (or better we have more tools). A lot of people did not updated packages for several releases, but now we can easily extract and analyze all archive, and correct bugs. It is also simpler: only a dependency, instead of analyzing upstream makefiles, and so on to adapt the paths. But maybe I'm really undervaluating the effort. 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 (part two)
Raphael Geissert writes (Switching /bin/sh to dash (part two)): * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. This needs to be done with great care to ensure that at every point there is a working /bin/sh. Naive use of diversions will not ensure this. I would suggest stracing (with -Fff) the dpkg -i run of the new dash package, to check that /bin/sh is updated in the proper manner. Ian. -- 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 (part two)
On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote: Why? Because: On Fri, Jul 24, 2009 at 09:38:01AM +0200, 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. 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. Those packages can be fixed if we want a nice, lean core system. -- 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 (part two)
On Fri, Jul 24, 2009 at 01:09:59PM +, Clint Adams wrote: On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote: Why? Because: On Fri, Jul 24, 2009 at 09:38:01AM +0200, 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. 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. Those packages can be fixed if we want a nice, lean core system. Patches will be considered. -- 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 (part two)
On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
Patches will be considered.
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst2009-07-24 09:00:38.0 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
# postinst based heavily on the postinst of libssl0.9.8, courtesy of
# Christoph Martin.
@@ -73,7 +73,7 @@
for service in $check; do
if [ -x `which invoke-rc.d 2/dev/null` ]; then
- idl=$(ls /etc/init.d/${service} 2 /dev/null | head -n 1)
+ idl=/etc/init.d/${service}
if [ -n $idl ] [ -x $idl ]; then
services=$service $services
else
--
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 (part two)
Clint Adams sch...@debian.org writes:
-idl=$(ls /etc/init.d/${service} 2 /dev/null | head -n 1)
+idl=/etc/init.d/${service}
if [ -n $idl ] [ -x $idl ]; then
You might as well remove the -n test if you do this. There's not much
chance of hitting it anymore...
Bjørn
--
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 (part two)
On Fri, Jul 24 2009, Steve Langasek wrote: On Thu, Jul 23, 2009 at 08:20:05PM -0500, Manoj Srivastava wrote: But well, one of the ideas is to avoid having such extra stuff deeply tied to the core system, i.e. essential. That's it? The time to try to reduce the set of Essential packages is to deny entry to new items (like dash), since once the package is essential, people (and not just package maintainers) come to rely on it. Our user base, in particular, has had 15+ years to rely on bash -- and there are loads of user scripts, support systems, cron jobs, third part packages -- that need bash. I think this is addressable by clearly documenting in Policy (where the handling of Essential packages is defined) that packages which invoke /bin/dash are required to depend on dash instead of relying on Essential. Then why make dash Essential, if using dash in packages will automatically pull it in? At that point, there seems to be no technical reason for essentialness; is there? manoj -- Two wrongs don't make a right, but they make a good excuse. Thomas Szasz 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 (part two)
Giacomo Catenazzi c...@debian.org writes: Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. One additional question: how can we setup dependencies, so that nis + mounted /usr/ needs explicitly dash as /bin/sh? [creating ugly dash-as-sh, bash-as-sh packages, who conflict each other and setup the symlink?] Or we need to set explicitly use #!/bin/dash in umountall? [not so flexible solution, but IMHO enough good] If it needs dash then yes, set #!/bin/dash and Pre-Depend on dash. But in this case that really needs to be fixed to work with any posix shell. I think we should address this, because was one of the rationale for the switch. In long term we need to find a solution how to handle unsupported configuration in a flexible way (which will solve also lilo case: it works only with limited kernels and config) ciao cate 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 (part two)
Hi Ian, Ian Jackson wrote: Raphael Geissert writes (Switching /bin/sh to dash (part two)): * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. This needs to be done with great care to ensure that at every point there is a working /bin/sh. Naive use of diversions will not ensure this. Sure, we've been very cautious, and we are even making dash provide /bin/sh. We'll be talking about this during the talk at debconf. I would suggest stracing (with -Fff) the dpkg -i run of the new dash package, to check that /bin/sh is updated in the proper manner. In theory the symlink is never actually removed (at one point we need to manually touch the link, but it's done with ln -sf). But good idea, I'll check with strace. P.S. no need to send me a copy of your messages. 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 (part two)
Goswin von Brederlow wrote: Giacomo Catenazzi c...@debian.org writes: Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. One additional question: how can we setup dependencies, so that nis + mounted /usr/ needs explicitly dash as /bin/sh? [creating ugly dash-as-sh, bash-as-sh packages, who conflict each other and setup the symlink?] Or we need to set explicitly use #!/bin/dash in umountall? [not so flexible solution, but IMHO enough good] If it needs dash then yes, set #!/bin/dash and Pre-Depend on dash. But in this case that really needs to be fixed to work with any posix shell. Substitute posix with debian and I'll agree: it is not a posix issue, the init.d scripts are outside posix environment: they should work also in a restricted environment (without some basic unix functionality). The issue was a busy /usr partition by shell (when umount /usr), thus not always easy to solve and it could be again a shell design. BTW it seems that all previous tries to remove the bug in bash failed. 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 (part two)
On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. Is this latter part actually needed, or do we just need some package in the required set to depend on it? Note that, when essential functionality is being split between packages, the authoritative way to handle upgrades is to have an existing Essential: yes package *Pre-*Depend on the new package; but we're not actually splitting any essential functionality in this case, since bash is still Essential and will still provide all the same functionality. If we're to have an Essential package depend on dash for upgrades, I suppose base-files is the obvious choice. -- 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 (part two)
Steve Langasek wrote: On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. Is this latter part actually needed, or do we just need some package in the required set to depend on it? Note that, when essential functionality is being split between packages, the authoritative way to handle upgrades is to have an existing Essential: yes package *Pre-*Depend on the new package; but we're not actually splitting any essential functionality in this case, since bash is still Essential and will still provide all the same functionality. No, the latter part is not necessary, though the consensus seemed to be that people did not want the change to happen without them having the chance to easily prevent it on upgrades. If we're to have an Essential package depend on dash for upgrades, I suppose base-files is the obvious choice. Well, bash is already doing it now and we did not want to bother people during d-i or debootstrap and having bash depend on dash made that easier. 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 (part two)
On Wed, Jul 22 2009, Giacomo A. Catenazzi wrote: If we remove the essential flag, we have a nice feature: the packages who needs bash need to be documented (via Depends). Can you tell me how long did it take to move from /usr/doc to /usr/share/doc? manoj -- Beware the one behind you. 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 (part two)
On Tue, Jul 21 2009, Giacomo A. Catenazzi wrote: but policy recommend not to use bash features on scripts (10.3), That happens to be not what policy actually says. and the availability of a POSIX-shell (with few extension) is already provided by policy (still 10.3), thus no need to add package dependencies. Unless you happen to use features of a package that been essential forever (in Debian years). And all policy says is that you have the magic #!/bin/bash at top. manoj -- Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great. 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 (part two)
On Tue, Jul 21 2009, Raphael Geissert wrote: Henrique de Moraes Holschuh wrote: It is not like you will be able to remove bash from the vast majority of the Debian systems out there anyway, so it doesn't matter if it remains essential for a while. The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. Can you explain why this added dependency is a good thing, apart from creating more work for people? manoj -- We demand rigidly defined areas of doubt and uncertainty! Vroomfondel 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 (part two)
On Tue, Jul 21 2009, Henrique de Moraes Holschuh wrote: On Tue, 21 Jul 2009, Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: But probably for the shell cases it is easier to remove 'essential' flag (especially for a minimal nearly POSIX-like shell like dash), because the interface of #!/bin/sh is defined in policy (10.3). Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. We can certainly retain bash as essential but still make dash essential and switch to dash. Can we refrain from this serial essentialness of the default-shell-du-jour, and arrange for some essential package to pull in the default shell for the day? I would be happier of we worked out a a way for the sysadmin to be able to specify the default shell for the machine, rather than have Debian decide it for them. This way, I can have a consistent /bin/sh across my machines, with different (supported) versions of Debian on them, even if Debian decides to change it's mind midway about what shell is king of the hill. Users may have tonnes of shell scripts (cron jobs, helper scripts, local commands) that use #!/bin/sh but have come to rely on the fact that for the last 16 years or so, /bin/sh reliably pointed to /bin/bash. The tradeoff of increased boot speed might not matter for users (certainly does not for me -- I only reboot to switch kernels), and adding dash or whatever incereases the disk usage for them (they need bash anywa, and so far have not needed dash -- so adding dash _adds_ to the bloat). manoj -- I'm going to give my psychoanalyst one more year, then I'm going to Lourdes. Woody Allen 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 (part two)
Manoj Srivastava wrote: I would be happier of we worked out a a way for the sysadmin to be able to specify the default shell for the machine, rather than have Debian decide it for them. There's already a way to do it: dpkg-reconfigure dash 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 (part two)
Manoj Srivastava wrote: On Tue, Jul 21 2009, Raphael Geissert wrote: The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. Can you explain why this added dependency is a good thing, apart from creating more work for people? I'd prefer if this is discussed when the proposal is actually made (not to mention that I'm not really the person who plans to carry it). But well, one of the ideas is to avoid having such extra stuff deeply tied to the core system, i.e. essential. 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 (part two)
On Thu, Jul 23 2009, Raphael Geissert wrote: Manoj Srivastava wrote: On Tue, Jul 21 2009, Raphael Geissert wrote: The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. Can you explain why this added dependency is a good thing, apart from creating more work for people? I'd prefer if this is discussed when the proposal is actually made And I prefer to cut off silly proposals in the bud, if at all possible, before significant effort is spent on it. The question is, is this proposal silly? In order to evaluate that, we have to find out _why_. The Embedded folk have made a reasonable argument for not wanting the weight of bash or zsh. Understandable, though it represents a smallish, competent section of the user base. (not to mention that I'm not really the person who plans to carry it). If you are really not the competent person to defend the idea, perhaps you should not be so free to assert it as a truism. But well, one of the ideas is to avoid having such extra stuff deeply tied to the core system, i.e. essential. That's it? The time to try to reduce the set of Essential packages is to deny entry to new items (like dash), since once the package is essential, people (and not just package maintainers) come to rely on it. Our user base, in particular, has had 15+ years to rely on bash -- and there are loads of user scripts, support systems, cron jobs, third part packages -- that need bash. Once something is marked essential, it takes a lot of pain to remove it, and transition the user base off the package. Oh, gee, I think it is a good idea to not have bash essential perhaps does not meet the cut when trying to determine if the pain that one must go through is worth the return. manoj leaning towards silly -- I couldn't possibly fail to disagree with you less. 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 (part two)
Giacomo A. Catenazzi c...@debian.org writes: Why? Always installed is different to essential, see e.g. libc. libc is essential from a Policy perspective. It's just not marked that way in the packaging system in case the SONAME changes, but it's essential in the same way that awk is. Note that dependencies on awk are not required (and indeed are a Lintian warning). I really think that some essential package would depends on bash (in this case would be passwd, who provides useadd/chsh/..). In which case bash should stay essential with the essential flag; if we're going to guarantee that it's part of the essential set anyway, may as well let everyone rely on all the things that entails. If we remove the essential flag, we have a nice feature: the packages who needs bash need to be documented (via Depends). I'm contrary to essential flags on shells, not because we should remove shells from debian systems, but I really think that explicitly documenting dependencies is really a good things for us and for interoperability. It sounds more like you're opposed to omitting dependencies on essential packages in general rather than wanting bash not to be essential. -- 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
Essential [Re: Switching /bin/sh to dash (part two)]
Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: Why? Always installed is different to essential, see e.g. libc. libc is essential from a Policy perspective. It's just not marked that way in the packaging system in case the SONAME changes, but it's essential in the same way that awk is. Note that dependencies on awk are not required (and indeed are a Lintian warning). No! ;-) Unfortunately essential has two meanings: - packages which are always required on every Debian system. - note: there is also the priority Required - note: mawk has priority required, it is not essential, but an essential package (base-files) predepends on it. - package who should not be written in the dependency list (but on versioned dependencies). I want to solve this question: What packages really depends on bash? Note: nine packages depends on mawk, so if we replace mawk with gawk (a trully virtual example) we know where to test the changes (because it not essential by the second rule). With bash we don't have such info. I accept that bash is required on every Debian system, but I would like to have explicit dependencies on bash. So for my point of view [weight on second interpretation], mawk, glibc are not really essential package. But I see your confusion, so I propose a change in policy: - essential will have only the first meaning - policy must explicitly enumerate the packages which don't require explicit dependencies. [for obvious reason these deb should be in the subset of essential or essential-like packages] ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Essential [Re: Switching /bin/sh to dash (part two)]
Giacomo A. Catenazzi c...@debian.org writes: Russ Allbery wrote: libc is essential from a Policy perspective. It's just not marked that way in the packaging system in case the SONAME changes, but it's essential in the same way that awk is. Note that dependencies on awk are not required (and indeed are a Lintian warning). No! ;-) Unfortunately essential has two meanings: - packages which are always required on every Debian system. - note: there is also the priority Required Which is not the same thing. - note: mawk has priority required, it is not essential, but an essential package (base-files) predepends on it. awk is essential. Specific awk implementations are not, but the interface is essential. This is something that we've discussed many times over the years and I'm absolutely certain that statement is correct. - package who should not be written in the dependency list (but on versioned dependencies). awk should not be written into the dependency list, because it is essential. I want to solve this question: What packages really depends on bash? Note: nine packages depends on mawk, If they need mawk in particular, they need to depend on it, but if they just need awk, they should not have a dependency. so if we replace mawk with gawk (a trully virtual example) we know where to test the changes (because it not essential by the second rule). Not if you need to check all the packages that depend on awk. So for my point of view [weight on second interpretation], mawk, glibc are not really essential package. But I see your confusion, so I propose a change in policy: - essential will have only the first meaning - policy must explicitly enumerate the packages which don't require explicit dependencies. [for obvious reason these deb should be in the subset of essential or essential-like packages] I think the best way to resolve the confusion is for you to bring your internal interpretation of essential in line with the definition the rest of the project uses. :) -- 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: Essential [Re: Switching /bin/sh to dash (part two)]
Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: Russ Allbery wrote: libc is essential from a Policy perspective. It's just not marked that way in the packaging system in case the SONAME changes, but it's essential in the same way that awk is. Note that dependencies on awk are not required (and indeed are a Lintian warning). No! ;-) Unfortunately essential has two meanings: - packages which are always required on every Debian system. - note: there is also the priority Required Which is not the same thing. - note: mawk has priority required, it is not essential, but an essential package (base-files) predepends on it. awk is essential. Specific awk implementations are not, but the interface is essential. This is something that we've discussed many times over the years and I'm absolutely certain that statement is correct. awk is a virtual package, so it could not be essential. Virtual packages have not package flags. mawk is alway installed (required and a dependency of an essential package). mawk provides awk, but mawk is not essential. - package who should not be written in the dependency list (but on versioned dependencies). awk should not be written into the dependency list, because it is essential. not with the essential flag so if we replace mawk with gawk (a trully virtual example) we know where to test the changes (because it not essential by the second rule). Not if you need to check all the packages that depend on awk. hmm. Your sentence is not so good ;-) Do you mean depend implicitly? I think the best way to resolve the confusion is for you to bring your internal interpretation of essential in line with the definition the rest of the project uses. :) Maybe. But now you enlarged the interpretation of 3.8 with indirect essential packages ;-) awk has no explicit Essential flag! ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Essential [Re: Switching /bin/sh to dash (part two)]
Giacomo A. Catenazzi c...@debian.org writes: Russ Allbery wrote: awk is essential. Specific awk implementations are not, but the interface is essential. This is something that we've discussed many times over the years and I'm absolutely certain that statement is correct. awk is a virtual package, so it could not be essential. Virtual packages have not package flags. I'm not sure what I can say here other than you're wrong. -- 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: Essential [Re: Switching /bin/sh to dash (part two)]
On 2009-07-22 18:06 +0200, Giacomo A. Catenazzi wrote: mawk is alway installed (required and a dependency of an essential package). Wrong, you can easily remove mawk if you like, as long as you have another package that provides awk: , | % LANG=C aptitude -s remove mawk | Reading package lists... Done | Building dependency tree | Reading state information... Done | Reading extended state information | Initializing package states... Done | Reading task descriptions... Done | The following packages will be REMOVED: | mawk | 0 packages upgraded, 0 newly installed, 1 to remove and 22 not upgraded. | Need to get 0B of archives. After unpacking 233kB will be freed. | Would download/install/remove packages. ` But you cannot remove _all_ packages providing awk: , | % LANG=C aptitude -s remove mawk gawk original-awk | Reading package lists... Done | Building dependency tree | Reading state information... Done | Reading extended state information | Initializing package states... Done | Reading task descriptions... Done | The following packages are BROKEN: | base-files dictfmt tla | The following packages will be REMOVED: | gawk mawk original-awk | 0 packages upgraded, 0 newly installed, 3 to remove and 22 not upgraded. | Need to get 0B of archives. After unpacking 2466kB will be freed. | The following packages have unmet dependencies: | base-files: PreDepends: awk which is a virtual package. | tla: Depends: gawk but it is not installable | dictfmt: Depends: gawk but it is not installable | The following actions will resolve these dependencies: | | Keep the following packages at their current version: | gawk [1:3.1.6.dfsg-3 (unstable, now)] | | Score is -9939 | | Accept this solution? [Y/n/q/?] q | Abandoning all efforts to resolve these dependencies. | Abort. ` Sven -- 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 (part two)
Raphael Geissert wrote: Giacomo A. Catenazzi wrote: My only doubt, also stated in previous thread is the dash essential. It is the goal of many people to remove bash (and dash) and some other packages from essential. But at this time, it is needed. In general it is very difficult to remove the essential flag from a package. 'Essential' has two meanings. From policy (3.8): Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. But probably for the shell cases it is easier to remove 'essential' flag (especially for a minimal nearly POSIX-like shell like dash), because the interface of #!/bin/sh is defined in policy (10.3). IMHO your third point make another essential package depend on dash. is it enough, but if we really need dash explicitly Essential, do it! 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 (part two)
Giacomo A. Catenazzi c...@debian.org writes: But probably for the shell cases it is easier to remove 'essential' flag (especially for a minimal nearly POSIX-like shell like dash), because the interface of #!/bin/sh is defined in policy (10.3). Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. -- 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 (part two)
On Tue, Jul 21, 2009 at 06:14:27AM -0700, Russ Allbery wrote: Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. I think it's certainly worth it in the long run. -- 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 (part two)
Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: But probably for the shell cases it is easier to remove 'essential' flag (especially for a minimal nearly POSIX-like shell like dash), because the interface of #!/bin/sh is defined in policy (10.3). Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. but policy recommend not to use bash features on scripts (10.3), and the availability of a POSIX-shell (with few extension) is already provided by policy (still 10.3), thus no need to add package dependencies. Apart of install scripts (which IMHO should be moved when possible to dash, for efficiency reason), I don't think there are so much shell scripts (or better: a large number but not a huge number), and some of such scripts really need to be run with dash for efficiency. For install script (on a server): grep -r '#! */bin/bash' /var/lib/dpkg/info/ | wc -l 26 grep -r '#! */bin/sh' /var/lib/dpkg/info/ | wc -l 1239 But i think we should do this discussion after next release. one small step for Debian, ... 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 (part two)
On Tue, 21 Jul 2009, Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: But probably for the shell cases it is easier to remove 'essential' flag (especially for a minimal nearly POSIX-like shell like dash), because the interface of #!/bin/sh is defined in policy (10.3). Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. We can certainly retain bash as essential but still make dash essential and switch to dash. It is not like you will be able to remove bash from the vast majority of the Debian systems out there anyway, so it doesn't matter if it remains essential for a while. The embedded crowd would want to find a way to get rid of bash, though, and trying to make bash a non-essential package seems like a worthwile effort because of that. It can even be reasonably automated, since you can rgrep /bin/bash to find out scripts that use it on packages that don't declare a dependency on bash... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 (part two)
Henrique de Moraes Holschuh wrote: It is not like you will be able to remove bash from the vast majority of the Debian systems out there anyway, so it doesn't matter if it remains essential for a while. The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. The embedded crowd would want to find a way to get rid of bash, though, and trying to make bash a non-essential package seems like a worthwile effort because of that. It can even be reasonably automated, since you can rgrep /bin/bash to find out scripts that use it on packages that don't declare a dependency on bash... Yes, most of it can be automated with scripts run debhelper and cdbs. 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 (part two)
Raphael Geissert wrote: Henrique de Moraes Holschuh wrote: It is not like you will be able to remove bash from the vast majority of the Debian systems out there anyway, so it doesn't matter if it remains essential for a while. The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. Yes, moving bash out of essential is a worthy goal, though I think we're not yet ready to do that: the move of the default system shell has not been completed and there are still quite some bashisms around... 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 (part two)
Henrique de Moraes Holschuh wrote: The embedded crowd would want to find a way to get rid of bash, though, and trying to make bash a non-essential package seems like a worthwile effort because of that. It can even be reasonably automated, since you can rgrep /bin/bash to find out scripts that use it on packages that don't declare a dependency on bash... I would say that as long as we keep bash as the default shell for users it should remain 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 (part two)
On Tue, Jul 21, 2009 at 01:22:47PM +, Clint Adams wrote: On Tue, Jul 21, 2009 at 06:14:27AM -0700, Russ Allbery wrote: Except that every package in Debian that explicitly uses bash has no declared dependency on bash because it's essential. I think attempting to go through and add all those dependencies and test would be a huge waste of time and resources. I think it's certainly worth it in the long run. Why? -- 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 (part two)
* Giacomo A. Catenazzi: but policy recommend not to use bash features on scripts (10.3), and the availability of a POSIX-shell (with few extension) is already provided by policy (still 10.3), thus no need to add package dependencies. When in doubt, use /bin/bash isn't really a recommendation not to use bash, is it? Apart of install scripts (which IMHO should be moved when possible to dash, for efficiency reason), I don't think there are so much shell scripts (or better: a large number but not a huge number), and some of such scripts really need to be run with dash for efficiency. Wouldn't it be better to spend the time on speeding up bash (in theory; I don't want to ask other people what to do with their spare time)? -- 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 (part two)
Frans Pop wrote: Henrique de Moraes Holschuh wrote: The embedded crowd would want to find a way to get rid of bash, though, and trying to make bash a non-essential package seems like a worthwile effort because of that. It can even be reasonably automated, since you can rgrep /bin/bash to find out scripts that use it on packages that don't declare a dependency on bash... I would say that as long as we keep bash as the default shell for users it should remain essential. Why? Always installed is different to essential, see e.g. libc. I really think that some essential package would depends on bash (in this case would be passwd, who provides useadd/chsh/..). If we remove the essential flag, we have a nice feature: the packages who needs bash need to be documented (via Depends). I'm contrary to essential flags on shells, not because we should remove shells from debian systems, but I really think that explicitly documenting dependencies is really a good things for us and for interoperability. 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 (part two)
On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. Is there a reason why we're not using the alternatives system for this and let both bash and dash set that up, and then have dash's priority lower than bash? (If you do this, please make sure that if you manaully select bash it doesn't change to dash again after an upgrade of either dash or bash.) Kurt -- 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 (part two)
On Mon, Jul 20, 2009 at 10:58:02AM +0200, Kurt Roeckx k...@roeckx.be wrote: On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. Is there a reason why we're not using the alternatives system for this and let both bash and dash set that up, and then have dash's priority lower than bash? Because the alternatives system can leave dangling symlinks in various cases. And guess what happens when /bin/sh is a dangling symlink. Mike -- 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 (part two)
On Mon, 20 Jul 2009, Mike Hommey wrote: On Mon, Jul 20, 2009 at 10:58:02AM +0200, Kurt Roeckx k...@roeckx.be wrote: Is there a reason why we're not using the alternatives system for this and let both bash and dash set that up, and then have dash's priority lower than bash? Why lower if we want dash to be the default? Because the alternatives system can leave dangling symlinks in various cases. And guess what happens when /bin/sh is a dangling symlink. Well, it has gotten better in that regard but I would still not advise to use it for /bin/sh. Cheers, -- Raphaël Hertzog -- 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 (part two)
Kurt Roeckx wrote: On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. I'm not sure what an interactive upgrade is. How do you detect that? Is that when it's not run from d-i or something? interactive is when it's not in d-i and has an interactive debconf frontend. Detecting it will probably mean looking if bash is installed or not (during d-i/debootstrap, we will make sure dash is installed before bash). Does this mean it's going to ask us on each upgrade? No, only on first installation. With the Depends you're letting people install it now, so on first _install_ it's going to divert it without prompt? Or is that part of the interactive upgrade? No, on first installation it will ask. 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 (part two)
Raphael Geissert wrote:
Hello everybody,
This is a follow up to my previous thread, with a slightly different proposal.
What actually needs to be done is:
* Make dash essential,
My only doubt, also stated in previous thread is the dash essential.
Technically I would prefer that:
- initscript package will depend on dash (because of nasty interaction
bash and mount on some nis configuration)
- package who requires dash or bash (or a specific version) will
explicitly use them in the dependencies.
Maybe also dpkg if {pre,post}{inst,rm} really need it
(but NOT for package who requires a generic POSIX shell)
It is more as a documentation effort. In general programs will use dash
by defaults.
This is like system libraries (libc) and libraries in general:
indirect essential.
make it divert the current /bin/sh symlink by default,
make another essential package depend on dash. Prompt the user before
diverting on interactive upgrades.
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 (part two)
Giacomo A. Catenazzi wrote: My only doubt, also stated in previous thread is the dash essential. It is the goal of many people to remove bash (and dash) and some other packages from essential. But at this time, it is needed. Cheers, Raphael Geissert -- 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 (part two)
Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. What won't change: * Bash will still be used as the default interactive shells for users. Side effects: * Errors caused by the use of bashisms. * Faster boot, builds, and general usage of /bin/sh scripts. * Reduced memory footprint when running /bin/sh scripts. Counter side effects: * Fix known bashisms, * rebuild the archive with dash as /bin/sh. Policy references: * Section 10.4[2]: Scripts may assume that /bin/sh implements the SUSv3 Shell Command Language 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 Facts: * Dash's inst popcon from Debian: 10733 * Over 783 issues detected and fixed * It's been more than three years since Ubuntu made the switch, without all the extra bashisms-hunting Debian has done, without rolling it back. References of interest: [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.orgtag=goal-dash [2]http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts [3]https://wiki.ubuntu.com/DashAsBinSh [4]http://manpages.debian.net/cgi-bin/man.cgi?query=checkbashisms [5]http://release.debian.org/lenny/goals.txt [6]http://lists.debian.org/debian-release/2009/04/msg00133.html Main diff between the previous proposal: Current installations will only be switched to dash if it was not previously installed and if you agree to make the switch (debconf prompt). Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net signature.asc Description: This is a digitally signed message part.
Re: Switching /bin/sh to dash (part two)
On Sun Jul 19 18:04, Raphael Geissert wrote: This is a follow up to my previous thread, with a slightly different proposal. proposal snipped Sounds like a good plan, I really hope we can go ahead with this for squeeze. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Switching /bin/sh to dash (part two)
On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. I'm not sure what an interactive upgrade is. How do you detect that? Is that when it's not run from d-i or something? Does this mean it's going to ask us on each upgrade? With the Depends you're letting people install it now, so on first _install_ it's going to divert it without prompt? Or is that part of the interactive upgrade? Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
