Dan Price wrote:
> On Thu 24 Aug 2006 at 04:07AM, Roland Mainz wrote:
> > >
> > > ``HORRIBLE'' appears to be a rhetorical overstatement
> >
> > It was not thought as "rhetorical overstatement" - it is what I think
> > how it will end. I've logged a few hundred hours getting various
> > scenarious tested and the two prototypes set up ("prototype001" was a
> > complete failure, partially because it tried to bypass the libcmd
> > problem) and I think I can at least outline the scenario of such a
> > implementation.
> >
> > But my first question would be: Who actually benefits from moving the
> > functions in the current Solaris libcmd.so to another library ? AFAIK
> > noone will benefit - but many [at Sun] will suffer. And the result will
> > not even be "more clean" than the current design.
>
> I think Alan, Jim and I have clearly articulated at least two clean
> ways to do this with expediency and minimal suffering.
But both proposals do not gurantee the full binary compatibility... ;-/
> As with many
> problems, you solve it in stages, not all at the same time.
I still think that such a work is just wasted engineering time. Do you
have any _technical_ reasons why the Solaris libcmd functionlity should
be kept seperate ? So far it seems the current proposal just involves
bureaucracy tasks to satisfy the needs of the bureaucracy while we will
not see any functional improvements in the situation, right ? And a
seperate library will also waste more memory than the current
solution... ;-(
> > > 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
> >
> > I'd suggest to dismantle libraries like "libnspr" or "libc", too - they
> > are merging various functionality and fusing them together in one
> > library. Or think about "librt" which was consumed by "libc" - that's
> > another example of such fusions.
>
> You've quoted one precedent which AFAIK OpenSolaris has no control over (nspr)
> and another which is totally orthogonal to the question before us (rt/aio).
>
> To address the rt/aio point: There are at times compelling architectural
> reasons to merge libraries-- in the case of aio and librt you had an
> intertwined set of libraries which knew about each other's innards. You
> should
> read 6416832. Here in part is what Roger wrote in that bug report:
[snip]
> > Folding all of libaio and librt into libc would solve these
> > dependency problems and yield a simpler and more stable system.
>
> So there you go--- merging these libraries yields a more architecturally
> clean whole, and reduces fragile cross-component dependencies. It passes
> the test with flying colors.
Ok... thanks for the background information... however if you want an
architectural "clean" solution we should move the |def*()|-functions to
libcmdutils.so and not in yet-another new library.
> This is very different from the current situation: "liba and liba have the
> same
> name, but are otherwise authored by different people, are architecturally
> distinct, and have distinct consumers" which appears to me to be the case
> before
> us.
The last point isn't completely correct - both Solaris libcmd and
ksh93's libcmd target commands as comsumers and at least the native
Solaris command versions of the ksh93 builtin commands provided by
libcmd have intersections - which quicky leads to the problem that
future changes in this area may force us to make libcmd.so depend on
liboldsolariscmdwithdeffunctions.so.666 ... ;-(
> > > 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.
> >
> > Erm... the last thing I heared is that libxml2 is moved into the OS/Net
> > codebase... or do I mix things up ? AFAIK the general policy is that
> > such extra dependicies should be avoided, right ?
>
> It is possible that someone is considering such a move. But if you check
> the source base, it currently isn't the case. While someone might
> correct me I don't know of a specific policy which dictates that
> cross-consolidation dependencies are inherently bad.
Umpf... I've been instructed otherwise and IMO OS/Net should remain
self-contained. It shouldn't really end like the DLL dependicy hell of
"Gnome" or "X.org after the great modularisation" ... ;-(
> > The integration into OS/Net is a requirement for the
> > "migration".
>
> Again, why? I don't see why the ksh93 must be in OS/Net to someday deliver
> the
> file /usr/bin/ksh.
Why isn't /sbin/sh then in /usr/sfw/bin/ ? Or /usr/bin/csh ? What about
/usr/bin/bc ?
> Now, you might make an argument around preservation of
> package boundaries (since packages don't span consolidations) or highlight
> some
> other intermingling between ksh and the rest of the system but I haven't seen
> such an explanation yet.
Umpf... we're having here a chicken&egg problem... partially. We want to
use libshell.so but need to get it into OS/Net first. But when ARC makes
it a requirement to present existing consumers in OS/Net we'll hit an
endless loop... ;-(
Please try to see ksh93 as new version of /usr/bin/ksh which already
lives in usr/src/cmd/ksh (or better: lived there until it was moved to
closedbins).
[snip]
> > For comparisation - building ksh93 with
> > the native build system can be VERY tricky as the built system in it's
> > default configuration probes the underlying build machine (and not any
> > proto area etc.) for information which makes it very tricky as even
> > minor changes in the build machine can turn features on/off - and that
> > would be a perfect "call generator". You can fix that - but then you're
> > getting more or less to that point where we are currently with our
> > integration into OS/Net... :-)
>
> If that is true, then it's a shame-- as a reference, how do other software
> distributions (debian, fedora, etc.) handle building a sane ksh93?
A common practice seems to be that they patch the source and the build
system to fit their needs and/or built the RPM as "root" and shuffel
some system files around to make sure the AST build system finds them at
the expected place (for example the Debian build server seems to install
only those packages listed in the built dependicies... others simply
wrote their own makefiles (like we did) or run some other stunts. For
example the "buildksh93.ksh" script I am using to build the header files
was originally a clone of how SuSE's RPM handles the job (their solution
includes building ksh93 via the normal build system (after applying
source patches and set CCFLAGS to include some AST-specific options,
overriding the "iffe" probe system) and then parse the build log,
extract the locations of the *.o files from there and construct the
shared libraries manually from these objects)). These things are more or
less done by trial&error testing and not really by design... ;-(
> > Question back: Why does "perl" actually live in OS/Net ? If I apply the
> > same pattern as your're using for ksh93 "perl" would be the last thing
> > needed in OS/Net... it could - in theory - happily live in /usr/sfw/hin/
> > ... =:-)
>
> Well I'll defer to Stephen and Alan Burlison on why perl needs to be in
> OS/Net (or if it must at all). It could be due to build system issues
> similar to the ones you have articulated. It may simply be grandfathered.
> I don't know. [Python OTOH is not in OS/Net].
And /usr/bin/ksh IS used by the OS/Net build system extensively. Almost
all larger scripts use /usr/bin/ksh. IMO ksh93 has - as the new version
and designated replacement - the "birthright" for an inclusion into
OS/Net. And it's integration into OS/Net may be very valueable as it
could help make scripts shorter, easier to understand and MUCH faster.
> > See above... there are items like the future "migration" of the old ksh
> > to ksh93 or (for example) Solaris-specific goodies that we're going to
> > add a 64bit ksh93 - for the first time Solaris would have a scripting
> > language which is capable to deal with large datasets (and ksh93 is NOT
> > slow :-) ), something which even "perl" didn't archive yet. And
> > applications in OS/Net may be intestested to use libshell.so which would
> > make the creation of all the "*adm" tools MUCH easier as they could be
> > build on top of libshell's customizeable framework (if you ever worked
> > with "dbx" - it's based on another bariant of "ksh" - and in the long
> > term it may be nice to switch "dbx" to use libshell to avoid the massive
> > code duplication the various Sun products).
>
> I'm not opposed per se to using libshell (I had some minor experience
> working on a research debugger many years ago which embedded ksh).
> Again, I believe that libshell could be in use by various consolidations
> while being delivered in the SFW consolidation.
Umpf... ;-(
And how should the version in the SFW consolidation be build ? How
should it be handled ? I started this project to get ksh93 integrated
into OS/Net that it can replace at some point the old ksh. An
integration into SFW would make it FAR more difficult to convince other
consolitations to use it and a replacement of /usr/bin/ksh will likely
become IMPOSSIBLE. An integration just into SFW would also mean that we
can completly abandon most of the other long-term goals (even such
low-hanging fruits like a common codebase for /usr/bin/printf,
/usr/bin/sleep, /usr/bin/cat, /usr/bin/wc etc. etc. will become
difficult as these tools like in OS/Net) for the possible usage of
libshell and libast and without users we should question why we should
integrate ksh93 into Solaris at all. In theory the old ksh is
"sufficient" (yes, it's buggy and the interoperability with non-Solaris
operating systems is almost zero, but it seems most people at Sun don't
care about such items...) ... ;-(
> To be clear, I'm glad that we all are getting ksh93; if it is possible for it
> to replace old-ksh with ksh93 in a clean way which doesn't cause breakage,
> then
> I'm for that, too. Onward and upward and all that.
>
> I am just trying to make sure that the plan here makes sense. If you
> convince me, I can hopefully be a helpful ally in helping you finish.
Yes, but you're giving me a hard time... total time to answer all emails
in this matter today: More than six hours... ;-((
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
