Re: Bug mass filling
Manoj Srivastava <srivasta@debian.org> writes:
> I personally think that maintainer scripts should allow for
> /bin/sh to be not bash; or there should be documentation to the
> effect that non bash /bin/sh is not supported.
People actually use non-bash shells as /bin/sh and I get real bugs filed
against my packages when this doesn't work. (Usually they're using ash
instead.) The recent effort to speed up the boot process also achieved
noticable gains by switching from bash to ash, so I expect that will
prompt more people to try this.
I don't think using any non-POSIX feature should be a policy violation,
probably. There are some that are in such widespread use and are
supported by all shells that weren't written specifically as test suites
that I think it's worthwhile making an exception for them. But using
general bash features in /bin/sh scripts really do break real systems.
> This is tension between quality of implementation (making sure
> that maintianer scripts do not fall on their faces wehen the user
> takes the supported action of chaning /bin/sh, and the new fangled
> rush to push things out on time, ready or not, that makes such bugs
> non RC.
> I still think we should go for quality of implementation.
> I also seem to be a minority in this regard.
I think it's reasonable to make some tradeoffs between release quality and
making a formal release that is a substantial improvement over stable. If
we try to get *everything*, we're basically leaving people with stable and
all of the RC bugs that were already in stable and have since been
discovered. There are some policy violations (such as ensuring every
package has binary-arch and binary-indep targets) that require a *lot* of
package maintainer bugging and NMUs. I think it's reasonable to tackle a
few of those for each release, and probably biting off more than we can
chew to try to tackle every one of them for a given release.
But, this does require that we try to prevent backsliding, and if we've
done a big push to get rid of a policy violation, we should keep that
violation RC for subsequent releases.
If it's not important enough to go fix every package that has the problem,
I think we should question whether it's correct to have it be a
requirement in policy.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: