On Thu, Jul 17, 2008 at 00:30:40 +0200, Mariusz Mazur wrote: > It's not a reliable system when any application can fail because it either > expects something that all of the other distros, except us, have (sh -> bash) ^^^^^^^
Unfortunately these apps do not expect anything - they have some piece of code just because it have worked while typing in dumb monkey-mode. I'd prefer not to use such apps as they are (let me repeat) serious security threat. Do you remember a situation a few years ago when some malicious code was inserted into ./configure script? PLD was not affected thanks to another PITA - AC/AM regeneration. > or we've done something to it without having much clue about original > developers' reasons for a particular choice (ripping out internal versions of > various libs). So just use binary shipped FF, OOo and other. And BTW it's not their choice again - they exist because of the same dumb monkey-mode coding. The Real Programmer ships patch for mainstream lib (like it was in FUR and librapi2), unless this library is seriously broken - in this case it shoudn't be used anyway. > If they in fact are, to the extent we're not as much of security zealots as, > say, openbsd, it's obviously better to patch them. Doesn't our patches go upstream? If they are rejected it usualy means, that authors are really dumb or don't give a shit. Either way we do The Right Thing. > Both the python and /bin/sh cases don't fall under any of the above. Let's > try > to be specific. OK, last time: bash is broken. I don't want this GNU/shitty shell even to be installed on my machines, unfortunatelly some idiots use its 'features', just because they are too lazy to read SUSv3 spec (like using ((var++)) instead of var=$((var+1))). > PLD also has The Right Way, the Have It Just Work rule. Non-interactive rpm > installations, sane and working out-of-the-box default configs, a lot > of %post scripts to make sure everything's integrated, etc, etc. Going > against de facto standards (/bin/sh) It is not de facto or not standard - I don't remember having it on some HP or AIX machines. > in-house) scripts are concerned. All other scripts should be run with what > their authors expected, and that's bash (the Have It Just Work rule). The I don't remember changing /bin/bash to be something different. And that is used when author EXPECTS it. > solution is quite trivial -- have our scripts invoke pdksh directly and leave > bash under /bin/sh. No - Have It Just Work rule is trivial other way: if a script is too messed just change bang line to bash. Bash seems not to care much of argv[0]. > Bottom line is -- we're quite an invasive distro anyway, as far as patching > apps goes, so it's in our best interest to get rid of those modifications > that have no real life value and are only a pain in the ass. /bin/sh has the same value as: 1. being FHS compliant 2. micropackages 3. spec files guidelines 4. lang() and %doc stuff > I'd urge the Th RM (well, Ti too ;) to Do The Right Thing wrt to both python > and sh/bash. If it's really an unpopular decision, it'll get overruled in > CDG. And if not, we'll have a few less quirks to irritate us. And you will have a few developers and users left, as PLD would have still less and less to offer. -- Tomasz Pala <[EMAIL PROTECTED]> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en