On Thu 24 Aug 2006 at 12:35AM, Roland Mainz wrote: > > I have a couple of questions regarding the shape of the > > project: > > > > - What is the nature of the replacing of libcmd.so? If I'm > > not mistaken, I noticed that the existing libcmd.so is > > being overwritten by the tarball which was recently > > published. I wondered why that would be. > > Both Solaris and ksh93/AST have a library called libcmd - for Solaris it > is an old "relict" from ancient times which currently only carries the > |def*()|-functions to read+parse files from /etc/default/. ksh93/AST has > a libcmd which contains some ksh93 builtin commands (those commands > which are not mandatory to get libshell up and running - those commands > live in libshell (David/Glenn may be able to explain that better)). > > We've looked at the problem and realised that renaming libcmd.so.1 will > be a HORRIBLE pain since many other consolidations depend on it, making
``HORRIBLE'' appears to be a rhetorical overstatement-- there is a problem here, and I feel that we should solve in an architecturally clean way-- I don't see why merging two completely unrelated libraries makes any architectural sense. Note also that libcmd can be renamed prior to the ksh93 putback as a separable entity-- this could be done by you, or by any other community member, or by an engineer who works for Sun. While it will require some cross-consolidation coordination, many projects do. While your project may require some cleanup to the source base-- guess what, that's what happens... > even the process of one or multiple flag days a serious pain. The pain > will even be MUCH harder because I am external contriutor which means > getting one or more flag days syncronised is almost impossible (for me). I agree that you'd need some assistance. C'est la vie. > Another option would be to rename ksh93's libcmd.so - but that would It's clearly not an option, and I have not (and won't) suggest it. > "closed") and /sbin/sh now lives. libshell (which is ksh93 made > available as shared library (which means that /usr/bin/ksh93 is just a > 5k-8k wrapper which directly calls into libshell code)) may be usefull > for other applications like zone/ufs/SMF (adminstration) tools > (supplementing or replacing libtecla) which make it mandatory that ksh93 > lives in OS/net directly. Your statement is inaccurate. Things in OS/Net can depend upon things not in OS/Net. For example, Zones depends upon libxml2, which is in SFW. > > understand that ksh93 has its own build system, and > > I was wondering which consolidation would best accomodate > > that uniqueness. > > We do not use the original AST build system for ksh93 in OS/Net - I Why not? Doesn't that just increase the maintenance burden when ksh93 revs to a new version? With the SFW build system, you just drop in the new .tar.gz, update some build metadata, and be done. > wrote Makefiles which works like all other OS/Net stuff. Everything is > done, see > http://polaris.blastwave.org/browser/on/branches/ksh93/gisburn/prototype002/m1_ast_ast_imported/usr/src It's pretty hard to work out what specifically this represents: how it is different from Dave Korn's ksh93, and what the delta is from the existing O/N gate; I would be aided greatly by a webrev, if you could point me to one. Setting that aside, the fact that something is finished doesn't make it correct. I don't see why we wouldn't just drop this into SFW, using its much simpler build system. Integration into ON means that it will be that much harder to rev ksh93, and swells up the consolidation. Again, what's the architectural reason for including this piece of free software into the OS/Net consolidation, when we already have a consolidation designed to accept pieces of free software? SFW is where bash, tcsh, zsh, apache, etc. live. In my mind, unless we're doing some really deep changes to enhance ksh and solaris-ify it (like with e.g. ipfilter), it doesn't really belong in ON-- and in fact putting in SFW should help us to resist that temptation. I'm less clear whether there are formal rules about this at the product level; but there probably should be. If you can articulate ways in which ksh is inextricably intertwined into the system in ways the 'bash' is not, then I'm interested to learn about them. To prioritize, my deepest concerns here are about (a) not reestablishing the practice of having large piles of asynchronously changing free software in OS/Net (i.e. I believe that 'sendmail' is grandfathered, not a precedent). (b) The practice of re-engineering something to fit into our build process when there is not a compelling case to do so. (c) The merging of libcmd with libcmd. It is possible that libcmd could be a forcing factor for inclusion within ON, but you've not articulated any architectural reason that solaris:libcmd.so can't be transformed into solaris:libcmd_private.so, have overstated the difficulty of such a change, and anyway, it seems like the tail wagging the dog. To reiterate, I'm interested mostly in the architectural cleanliness of the project, and that things are done with appropriate rationale-- number of commits, number of customers requesting, and even backportability are in my mind at best secondary concerns. You have done an admirable job blazing a trail to accomplish a large and complex project. I'm part of the system of checks and balances which helps to make sure that we're doing things "right" not just "with inertia." And making sure it is clean architecturally and in terms of maintainability sets a really strong precedent for future work. > The current solution for libcmd based on Sun's prefernce for > backwards-compatibilty and MANY MANY other issues were addressed this > way, too. Just renaming the Solaris version of libcmd.so and annouce a > "flag day" isn't even 5% of the work which would need to be done (and I > expect around three/four months/engineer to get that propperly done). Like you, I write code for a living. So I didn't make this suggestion until after I had evaluated at least in part the feasibility of this change; Alan may be able to provide some more data (as he knows about CDE, JDS, etc), but I don't see why this change is so onerous: no ARC case (or a minimal one) would be needed, and notification to other consolidations of the date of the change and some commitment to make the appropriate makefile changes from them would be it. A putback to OS/Net altering several dozen makefiles would be needed. Cleverly doing this (with some symlinks) would even yield the ability to deliver this to ON, then get other consolidations updated. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
