Peter Memishian wrote: > > > * Webrev only over files which match the substring "makefile": > > > http://www.nrubsig.org/people/gisburn/work/solaris/ksh93_integration/ksh93_integration_prototype005_webrev_20070606/makefile_files/webrev/ > > Roland, > > Apologies if this has already been discussed, but what makes use of the > ON_BUILD_KSH93_AS_BINKSH logic?
Currently there a two points controlled by this switch: - The name under which ksh93 get installed (e.g. /usr/bin/ksh93 or /usr/bin/ksh) - Which version of |libc::wordexp()| is used. This is the critical issue why ths this switch&&related code was added. Currently |libc::wordexp()| depends on a "secret" switch added to Solaris /usr/bin/ksh to do the word expansion. ksh93 lacks this option and therefore |libc::wordexp()| will fail, in the worst case taking down or crashing the whole SMF service and rendering a system completely defunct (e.g. no runlevel changes possible and reboot won't help you either). To solve this non-trivial problem (e.g. deploying source patches for this was only partially successfull since the patched need constant maintaince) we added this switch and developed a version of |libc::wordexp()| which works with ksh93 (or any other modern POSIX-conformant shell). Otherwise the OpenSolaris distributions cannot replace /usr/bin/ksh with ksh93 (because it would blow-up SMF). And we need exactly those data from the OpenSolaris distributions to have "data from the wilderness out there" to proove that replacing /usr/bin/ksh doesn't cause any major harm to customers. Additionally we use this switch for testing, e.g. a quick, easy and _tested_ way to deploy ksh93 as /usr/bin/ksh for testing&&evaluation without ending in the trap called "wordexp()" each time you forgot to patch all vesions of libc.so.1 More information can be found by using Google... AFAIK we had these rants around fivehundredzillion times (and rants, flamewars, begging and finally a build switch to get rid of this pain) ... ;-( > What ensures the packaging will end up > correct when it's set? Currently the package database will not be adjusted automatically. Consumers will either ignore the issue (depending on whether they need (and/or rely on) the SysV package database) or patch the package database to match their needs (which is likely done by them anyway for other stuff). In theory we could adjust the package database automagically but we do not have a precedent for a package content list which is generated/altered at build time and therefore we dropped this part (e.g. we could add this feature but we avoided it for now since we thought that it may be difficult to get such a thing through review). > Will other distributions set it? Yes, primarly users of this flag are the non-Solaris OpenSolaris distributions and compatiblity testing for the migration work, e.g. we cannot move forward with the migration work without this switch. AFAIK most of the OpenSolaris distributions will enable this switch from the beginning to get rid of a large set of "evil" closed-source binaries. > Will it be > documented somewhere (e.g., in the developer env file)? Uhm... good question... erm... those who need the switch are aware of the issue and know the switch... but I am not sure whether we should "officially" document it or not... somewhere in my brain is a huge imaginary sign for this switch which says: "EXPERIMENTAL, USE AT YOUR OWN RISK. May cause exploding kitten. May cause the end of the universe. May... " ... > Also, why do we > create pfksh as an alias only when it's set? PSARC 2006/550 ripped-out (or better: "deferred") the creation of /usr/bin/pfksh93 thanks to the bickering about "builtin commands vs. RBAC". Since some setups depend on pfksh we either have the choice of a) breaking things by obmitting /usr/bin/pfksh93 or b) cause a theoretical hole which (in theory) may cause problems for RBAC scripts based on pfksh. I've picked choice [b] because the border-case of triggering builtin-related problems is very unlikely and there are two known workarounds (e.g. either specify the full path of the command which should be RBAC'ed or use $ builtin -d <name-of-builtin-which-should-be-disabled> #) to deal with the problem (and IMO RBAC is wrong because it violates the POSIX shell standard in it's current implementation (no, please don't start the rants again... thanks...)). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
