On 8/24/06, Dan Price <[EMAIL PROTECTED]> wrote:
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 - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
ksh93-integration-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
It is interesting to observe that each time the project reaches
another milestone a Sun employee steps in and demands a full change of
the project.
Very suspicious.
Is Sun actually interested in a ksh93 migration or did Sun only allow
the creation of this project to wear down the ksh93 migration
supporters to a point where they give up themselves?
Maybe IBM is right and Opensolaris is just a big FAKE project and
contributions by external persons are only taken if they please Sun
--
// Martin Schaffstall
// EMail: [EMAIL PROTECTED]
\\ //
\X/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
