> To: Joseph Kowalski <Joseph.Kowalski at eng.sun.com> ... > Joseph Kowalski wrote: > > > From: April Chin <April.Chin at eng.sun.com> > > > There were many programs found linking to libcmd in other consolidations > > > and unbundled products...coordinating the changes for > > > these consumers with the ksh93 project made it very difficult > > > to change the name of the Solaris libcmd. > > > > Oh sigh,... We can call it Consolidation Private, but it sounds like > > we got no respect... 8^) > > > > Actually, considering the nature of the routines I don't find it at > > all a surprize that others have latched on to these. As a matter of > > fact I recall a discussion about making these routies Public, but > > that was decided against because we didn't want to encourage the > > use of /etc/default when we knew SMF was coming. > > Making the |def*()| functions "public" should be avoided. Both the API > and the implementation can only be described as hack where hacks have > been tacked-on where hacks have been added where then additional hacks > have been added and hacks were introduced to deal with other broken > hacks. IMO it may be nice to create a lightwheight (e.g. no other > library dependicies than libc), threadsafe and locking-free replacement > API which should then live in libcmdutils.so.1 (and I volunteer to do > the work after ksh93 has been putback - that's easy... :-) ).
I didn't mean to suggest they should be made public. With SMF, they (and /etc/default) should be made Obsolete. Heh, less work for you. > > What about ksh98's libcmd. Why is this considered Public? (If it > > is Public, where are the man pages?) > > I consider it more or less "public" (note that I am always getting the > official Sun stabilty terminology wrong - April may correct me if I am > causing havic again... :-) ) because the API is stable since many many > years and will remain stable as far as I can see into the future. stable in the sense of not changing is almost completely unrelated to the concept of Stable in the taxonomy. That's why we changed the name in the new taxonomy to Comitted. We knew we were at odds with common usage of "stable" among the communities. Public is strictly who we support if they use it. The Public taxonomy levels are now, Committed, Uncommitted and Volatile. Anybody can use them and be supported. The difference is at what points in time the contract offered by the interface may change. Public and "man page" almost map 1:1 in the OpenSolaris/ON context. > Moreover we will have a bunch of follow-up projects which will quickly > make use of these builtin commands in libshell&&libcmd (e.g. we will > likely see the matching ARC case attack your mailinglist within one or > two weeks after the ksh93 putback is complete... :-) ) ... Which is irrelevant. You could do those changes with these being Private (either Project Private or Consolidation Private). Making them Public is all about publishing man pages and allowing the whole world to use them. I don't see that as part of at least this case as presented. More importantly, this question is a backward looking question. Even if these are to be made Public in the future. The question is if they were made Public in the past. Its actually (from other responses) narrower than that. The question is if the name libcmd (as in -lcmd) was publically documented. Could we change the name (to avoid the conflict) and no user would be the wiser? (Remember, we are talking about binary users here, not OpenSolaris developers.) In short, its a really gross hack to merge two relatively unrelated libraries because their historical names collide. Please work with us to find a better solution to this problem. Your parenthetical comment (smiley and all) makes me want to make sure we get the interface stability level of these interfaces correct as part of this case. At the moment, I'm not sure what the correct answer is, but I suspect it is some form of Private. - jek3
