FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-11-2008, 06:54 AM
William Pitcock
 
Default dash bug which is affecting release goal

Hi,

On Sun, 2008-02-10 at 23:48 -0500, Thomas Bushnell BSG wrote:
> On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote:
> > So we should also never upgrade /usr/bin/python, /usr/bin/perl, or
> > /usr/bin/gcc to point at a new upstream version because users may
> have local
> > programs that assume particular non-standard behavior from these
> programs,
> > right?
>
> I think that's a different case. There is a big difference between a
> newer version of the same program and a totally different program with
> fewer features.
>

It's possible for programs to completely change between versions. There
really is no difference in reality between switching from program A to
program B and switching from program A 1.1 to 1.2. The risk of problems
is exactly the same.

William
 
Old 02-11-2008, 08:33 AM
Mike Bird
 
Default dash bug which is affecting release goal

On Sun, 10 Feb 2008 21:40:14 Raphael Geissert wrote:
> I've already changed my /bin/sh and I've found very very few
> broken/missbehaving scripts.
> And as a great pro my boot time is more than 50% faster now, not to mention
> that the overall /bin/sh scripts run faster now.

Debian should ensure that millions of Debian users around
the world who have written and tested millions of tiny shell
scripts with no thought to the possibility that /bin/sh may
one day become not-bash will not suffer millions of hours
of down time (or worse - bad data) due to a Debian change.

I'm an old software engineer whose experience spans toggling
programs into the front-panel of an 18-bit PDP-7 through to
bleeding edge AI research. Despite years of endeavoring to
design software that is correct, maintainable, reliable, and
secure there is no way I could swear that all the little shell
scripts I've ever generated will work with a shell other than
that they were tested on.

On *production* Debian systems, saving 30 seconds in a boot
which may occur once a year for a kernel security update is
not worth a single broken script, nor a single failed backup,
nor a single lost data bit.

I see no problem in allowing users to knowingly change their
/bin/sh and suffer the consequences of their action if that
be their choice.

Nor do I contest that forcing a change of /bin/sh is legal
within Debian's framework of rules, but I do assert that
hurting millions of Debian users through such a change would
be extremely detrimental to both Debian users and Debian.

I'd much prefer that Debian changed its own scripts to use
#!/bin/sh.minimal without affecting user scripts, where
/bin/sh.minimal could be linked to any shell meeting Debian's
minimal criteria.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 09:20 AM
Cyril Brulebois
 
Default dash bug which is affecting release goal

On 11/02/2008, Mike Bird wrote:
> Debian should ensure that millions of Debian users around the world
> who have written and tested millions of tiny shell scripts with no
> thought to the possibility that /bin/sh may one day become not-bash
> will not suffer millions of hours of down time (or worse - bad data)
> due to a Debian change.

If those users are running unstable or testing, that's their job to
track such changes. If they are running stable, that's where Release
Notes can be used.

> On *production* Debian systems, saving 30 seconds in a boot which
> may occur once a year for a kernel security update is not worth a
> single broken script, nor a single failed backup, nor a single lost
> data bit.

Since you're talking about *production* systems, “stable” case above,
so “not a problem”.

Cheers,

--
Cyril Brulebois
 
Old 02-11-2008, 09:48 AM
Mike Bird
 
Default dash bug which is affecting release goal

On Mon February 11 2008 02:20:26 Cyril Brulebois wrote:
> On 11/02/2008, Mike Bird wrote:
> > On *production* Debian systems, saving 30 seconds in a boot which
> > may occur once a year for a kernel security update is not worth a
> > single broken script, nor a single failed backup, nor a single lost
> > data bit.
>
> Since you're talking about *production* systems, “stable” case above,
> so “not a problem”.

Release notes do not offset the millions of person-hours needed to review
and maybe-rewrite and retest the millions of tiny shell scripts that have
been written and tested by millions of Debian users with no thought to the
possible consequences of subsequent changes to /bin/sh.

Why do you believe it is better for Debian to harm millions of Debian
users rather than simply using #!/bin/sh.minimal within Debian scripts?

--Mike Bird
 
Old 02-11-2008, 10:39 AM
Bas Wijnen
 
Default dash bug which is affecting release goal

On Mon, Feb 11, 2008 at 02:48:33AM -0800, Mike Bird wrote:
> On Mon February 11 2008 02:20:26 Cyril Brulebois wrote:
> > On 11/02/2008, Mike Bird wrote:
> > > On *production* Debian systems, saving 30 seconds in a boot which
> > > may occur once a year for a kernel security update is not worth a
> > > single broken script, nor a single failed backup, nor a single lost
> > > data bit.
> >
> > Since you're talking about *production* systems, “stable” case above,
> > so “not a problem”.
>
> Release notes do not offset the millions of person-hours needed to review
> and maybe-rewrite and retest the millions of tiny shell scripts that have
> been written and tested by millions of Debian users with no thought to the
> possible consequences of subsequent changes to /bin/sh.
>
> Why do you believe it is better for Debian to harm millions of Debian
> users rather than simply using #!/bin/sh.minimal within Debian scripts?

Because that's what Debian does: we fix things, even when they work
while they are broken. A script which says #!/bin/sh, but which really
needs bash, is a bug. Debian doesn't want those bugs. This means a
transition which is some work, but we'll do it. Admins who wrote their
own shellscripts may also need to check if they still work. If they
don't trust it, then they should just set their shell to bash again.
Admins who maintain a system that cannot afford some downtime, and who
refuse to read the release notes when upgrading... well, they deserve
what they get, I think.

This fix requires quite some work on our part (not that I'm personally
working on it, but I see it being done ;-) ). A corporation would
likely follow your approach and leave things buggy (but working).
Debian aims to build the perfect OS. That means no bugs at all. We may
not reach that goal, but we'll get as close to it as we can. When we
see a bug, we try to fix it. This is a bug, even if it doesn't hurt
much. So we will fix it.

I think you're overestimating the damage this does to users. Most users
don't install things with scripts from outside of Debian. For those
users, we do the testing, and everything will continue to work. For the
users who do install external (home-made, for example) scripts, there
are two categories: Sensitive systems, where the admin should not accept
the change; those admins can be expected to read the release notes and
do what they should. And other systems, where the admin can notice that
things don't work anymore, and fix it when that happens.

This last category of users is the one which have the problems you fear.
I think this is a small group, and they should be able to handle it. I
am in that group myself, and that sort of problems is what I expect when
I upgrade my server (running stable) to the next release.

For newly installed systems, there is no problem at all. They will test
their new scripts on their new system and tweak them so they will work
on them. Which means less bugs. :-)

Thanks,
Bas

--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
 
Old 02-11-2008, 10:58 AM
Mike Bird
 
Default dash bug which is affecting release goal

On Mon February 11 2008 03:39:06 Bas Wijnen wrote:
> > Why do you believe it is better for Debian to harm millions of Debian
> > users rather than simply using #!/bin/sh.minimal within Debian scripts?
>
> Because that's what Debian does: we fix things, even when they work
> while they are broken. A script which says #!/bin/sh, but which really
> needs bash, is a bug. Debian doesn't want those bugs. This means a
> transition which is some work, but we'll do it. Admins who wrote their
> own shellscripts may also need to check if they still work. If they
> don't trust it, then they should just set their shell to bash again.
> Admins who maintain a system that cannot afford some downtime, and who
> refuse to read the release notes when upgrading... well, they deserve
> what they get, I think.

Debian has a policy which allows it to inflict this change on DD's, but
it is perfectly reasonable for Debian users to have determined that
/bin/sh was linked to bash and for Debian users to assume that /bin/sh
will not be changed for no good reason.

Furthermore, many tiny shell scripts are written by marginally technical
people, perhaps by copying and adapting something from a book or web page,
and they have no conception of the existence of different shell dialects
and would not think kindly of a distro that broke their little jewels for
no good reason.

DD's are welcome to spend as much effort as they choose in fixing this
non-bug in their own scripts, but sabotaging the millions of tiny scripts
written by Debian users is counter-productive, can only harm Debian's
reputation, and has no upside whatsoever.

Debian should use #!/bin/sh.minimal for its own scripts and not wantonly
break users' scripts; should not wantonly waste users' time in reviewing,
repairing, and retesting working scripts; and should not wantonly cause
outages, data loss, and data corruption - all of which are guaranteed
in large numbers because even the best of programmers make some mistakes
and a lot of tiny shell scripts in the big wide world are written by
people who are not the best of programmers.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 11:19 AM
Frans Pop
 
Default dash bug which is affecting release goal

Mike Bird wrote:
> Debian should ensure that millions of Debian users around
> the world who have written and tested millions of tiny shell
> scripts with no thought to the possibility that /bin/sh may
> one day become not-bash will not suffer millions of hours
> of down time (or worse - bad data) due to a Debian change.

Hmmm. To be honest up till now I was assuming that the change of the default
would only affect _new_ installs and that existing systems being upgraded
from Etch to Lenny would be unaffected.

Was that an incorrect assumption?

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 11:26 AM
Holger Levsen
 
Default dash bug which is affecting release goal

Hi,

On Monday 11 February 2008 11:48, Mike Bird wrote:
> > > On *production* Debian systems, saving 30 seconds in a boot which
> > > may occur once a year for a kernel security update is not worth a
> > > single broken script, nor a single failed backup, nor a single lost
> > > data bit.
> > Since you're talking about *production* systems, “stable” case above,
> > so “not a problem”.
> Release notes do not offset the millions of person-hours needed to review
> and maybe-rewrite and retest the millions of tiny shell scripts that have
> been written and tested by millions of Debian users with no thought to the
> possible consequences of subsequent changes to /bin/sh.

That might be right (or not) but it's irrelevant here. The proposed change is
to make dash the default /bin/sh for *new* installations, not to make this
change on upgrades from stable etch to stable lenny.

And if you bring new servers in production using a new release, without
testing for breakage, well...


regards,
Holger
 
Old 02-11-2008, 11:42 AM
Ben Finney
 
Default dash bug which is affecting release goal

Mike Bird <mgb@yosemite.net> writes:

> Debian has a policy which allows it to inflict this change on DD's,
> but it is perfectly reasonable for Debian users to have determined
> that /bin/sh was linked to bash

Yes.

> and for Debian users to assume that /bin/sh will not be changed

No. Why is this assumption reasonable?

> for no good reason.

This thread has listed many good reasons.

--
"All persons, living and dead, are purely coincidental." -- |
` _Timequake_, Kurt Vonnegut |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 12:19 PM
Andreas Bombe
 
Default dash bug which is affecting release goal

On Mon, Feb 11, 2008 at 02:48:33AM -0800, Mike Bird wrote:
> Release notes do not offset the millions of person-hours needed to review
> and maybe-rewrite and retest the millions of tiny shell scripts that have
> been written and tested by millions of Debian users with no thought to the
> possible consequences of subsequent changes to /bin/sh.

How many million person-hours does it really need to substitute
"#!/bin/sh" by "#!/bin/bash" once per script? That's even easily
scriptable, and I don't see the need for any amount of reviewing and
testing for such simple a bug fix.

--
Andreas Bombe <bombe@informatik.tu-muenchen.de> GPG key 0x04880A44


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 10:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org