>I think you will still get that answer when you ask in
>news:comp.unix.solaris (e.g. this knowledge doesn't seem to be
>well-known outside Sun...) ... ;-(
Yes, but that doesn't mean that the answer is basically "wrong" in
the sense that the answer usually includes arguments like:
- root's shell is used during boot (false)
- root's shell is used for certain scripts (false)
- root's shell should be statically linked (false, very much
so in Solaris 10)
Only the last answer was ever appropriate for earlier releases;
the second argument was partially appropriate when our /etc/rc?.d scripts
did not all start with #!.
>Uhm... I do not think it is "stupid" to split "/" and "/usr" - sometimes
>it is usefull to do it for performance or other reasons (like using
>seperate physical disks for "/" and "/usr") ...
For performance reasons? C'mon.
The reason a split "/" and "/usr" is *stupid* is fairly simple; there
are precious few scenarios which you can recover without /usr.
(E.g., you can *always* mount "/" because the kernel boots from it and
knows the boot device; but there are many scenarios where the /usr cannot
be mounted and where recovery is not possible, e.g., when the devices
pointing to the disk are not in the filesystem)
>Why doesn't apply the same argumentation to "libshell in the root
>filesystem", too ?
Because we need one shell and /sbin/sh suffices for now.
>I was thinking more about having a (near-) POSIX-conformant shell around
>at startup time and single-user mode, something which is easy to use,
>doesn't have the habit to turn the life of admins into a living hell in
>emergencies, can be used in jumpstart, pkgadd/pkgrm
>preinstall/postinstall/precheck/preremove/postremove scripts, boot time
>scripts and allow a high amount of "portability" between operating
>systems.
All of these need /usr present.
Also, you won't be able to use ksh93 for pkg* install scripts for a while
to come. At least not for scripts which are shipped as part of Solaris.
The reason is "liveupgrade" and other modes of operation where packages
are added while the tools are running on older revisions of the OS
(upto two or three releases back). So when ksh93 comes a standard item
in S11, you can not depend on it in pkg* tools until Solaris 13.
>Why should the installer be "broken" when it uses this choice by default
>? It is a valid choice in Unix to have "/" and "/usr" on seperate
>filesystems and it is AFAIK still needed for diskless client support and
>zones (please correct me if I am wrong).
Because the default is not helpful and leads to all sorts of issues
when space crunch happens.
There is NO good reason for a separate /usr on the root of a non-diskless
system.
There is NO good reason to grow "/" as opposed to "/usr" because there's
nothing you can do with just "/" mounted anyway.
>> Why? Why do we want to burden these programs with libshell?
>
>Why not ?
The onus is on the project team to provide arguments. As Dave said
"this is news to the SMF team".
I'm not saying that we should avoid using libshell in SMF at all costs,
but I have yet to see a reason, let alone a compelling reason, for it
to use libshell.
>- |libc::wordexp()| currently uses the old Solaris /usr/bin/ksh but
>should use "ksh93" in the future. Since libc sits in "/lib" it may be
>nice to have a copy of ksh93 in the root filesystem, too - otherwise
>|libc::wordexp()| will only work when "/usr" is mounted
So this currently doesn't work when /usr isn't mounted.
>- Replace some of the standalone commands with the libshell builtins
>(low-hanging fruits include "sleep", "pwd", "test" etc.)
All programs living in /usr
>- Think about { SMF, zone adminstration tool } which can be scripted
>(and do event-driven+conditional tasks) using shell functions and
>scripts (similar how dtksh/tksh can run shell functions as callback
>hooks)
All tools living in /usr.
>> The ARC has traditionally resisted "frameworks" which did not
>> have consumers; I see no concrete examples of such consumers.
>
>ksh93 has no "concrete consumers" either right now, too - using this
>kind of argumentation we could cancel this effort completely.
No, that's not true. "ksh93" is the project in itself and it is
clearly a usable and long-overdue addition to Solaris.
It is not a "framework" so it does not need consumers; but all the other
bits of ksh which are dumped all over the place are a framework
and I am still wondering why they need to be in /lib and /sbin.
>> And what is preventing these followon projects to move the library?
>
>It needs to be ARC'ed - again. Based on the current resistance we will
>either get libshell in /lib now or simply forget such projects
>completely because in a second/third/etc. attempt we will face the same
>argumentation+resistance. It's IMO useless to start projects or even
>consider them when there is little chanche of success.
I think you are taking the resistance entirely too personal; the
resistance against stuff in "/" is simply because there are no
arguments to do so. Once a project is submitted which requires
libshell to be moved to /lib then approval is a no-brainer.
>Think about pkg preinstall/postinstall/precheck/preremove/postremove
>scripts or custom install scripts which need to be run before "/usr"
>gets mounted...
There is no such situation. In the install situation, "/usr" is always
present. (And none of the install tools work when /usr is absent)
Casper
