Casper.Dik at Sun.COM wrote:
>
> >The updated proposal lists the files that will be in root.
> >
> >Yes, the root files are only libcmd and libast:
> >/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
> >/lib/libast*, and /lib/{amd64,sparcv9/libast*.
>
> And please make sure it is lazyloaded (libcmd is
>The updated proposal lists the files that will be in root.
>
>Yes, the root files are only libcmd and libast:
>/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
>/lib/libast*, and /lib/{amd64,sparcv9/libast*.
And please make sure it is lazyloaded (libcmd is pulled in by a large
proportion of applicati
Nicolas Williams writes:
> > The existing /lib/libcmd.so.1 is already located on the root filesystem,
> > is currently used by applications that may require the ability to work
> > with
> > only root filesystem access, and will have a dependency upon libast.
> > The libcmd dependency requi
Joseph Kowalski writes:
> However, because of all the discussion, I just want to verify the following.
We also have to clarify what goes on root. I think it's at most just
libcmd and libast, as the others seem to have nothing to do with the
problem. (And libast could be excluded by using a lazy
On Tue, Sep 26, 2006 at 10:43:51AM -1000, Joseph Kowalski wrote:
> April said:
>
> 2) /lib/{libast*, libdll*, libshell*} on the root filesystem
> The project team agrees to altering the case, such that the libdll and
> libshell libraries and links will be delivered on /usr/lib only.
> Th
On Tue, Sep 26, 2006 at 10:46:46AM -1000, Joseph Kowalski wrote:
>
> > From: Nicolas Williams
> ...
> > IMO def*() should be contracted for using existing default files (and
> > variables) *only*.
> >
> > For example, if there was a new GUI utility that needed to process
> > /etc/default/su in o
On Tue, Sep 26, 2006 at 10:24:50AM -1000, Joseph Kowalski wrote:
> > From: April Chin
> > AT&T will not be renaming the library nor changing its location.
> > External applications will want to use the AT&T interfaces, so the
> > project team does not want to rename the AT&T libcmd on Solaris
> >
> Date: Tue, 26 Sep 2006 10:24:50 -1000 (HST)
> From: Joseph Kowalski
> Subject: Re: Issue Summary Re: Korn Shell 93 Integration [PSARC-EXT/2006/550
Timeout: 09/27/2006]
> To: PSARC-EXT at sac.sfbay.sun.com, April.Chin at eng.sun.com
> Cc: ksh93-integration-discuss at opensolaris.org, roland.ma
The updated proposal lists the files that will be in root.
Yes, the root files are only libcmd and libast:
/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
/lib/libast*, and /lib/{amd64,sparcv9/libast*.
April
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Tue, 26 Sep 2006 16:35
> A future goal will be to replace Bourne shell, /sbin/sh, with ksh93.
That should be a point to debate in a future case; and should not be
a statement of intent.
tim
So is this better worded as
"A future goal may be..." ?
Thanks,
April
> Date: Tue, 26 Sep 2006 13:35:39 -0700
> From: Tim Marsland
> To: April Chin
> Cc: PSARC-EXT at sac.sfbay.sun.com, ksh93-integration-discuss at
> opensolaris.org,
roland.mainz at nrubsig.org, don.cragun at sun.com
> From: Nicolas Williams
> > Could be. My intent is to limit proliferation. I think both proposals
> > accomplish that. (I think yours is just a bit more work.)
>
> Code/feature duplication resulting from NOT using def*() to process
> existing /etc/default/ files would be more work as we
> From: Nicolas Williams
...
> IMO def*() should be contracted for using existing default files (and
> variables) *only*.
>
> For example, if there was a new GUI utility that needed to process
> /etc/default/su in order to be consistent with su(1) then it should use
> libcmd:def*() under contrac
> From: James Carlson
...
> Joseph Kowalski writes:
> > However, because of all the discussion, I just want to verify the following.
>
> We also have to clarify what goes on root. I think it's at most just
> libcmd and libast, as the others seem to have nothing to do with the
> problem. (And l
> From: April Chin
...
> 4) There was a lengthy discussion concerning merging the existing
> Solaris libcmd Sun Private interfaces and the new AT&T libcmd b_*()
> built-in command interfaces (Project Private now, but the project team
> expects that they will be made committed Committed Public in
15 matches
Mail list logo
