Manoj Srivastava <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]