Joseph Kowalski wrote:
>
> Let's cut this off...
>
> Garrett said that if the headers and manpage for the PRIVATE
> implementation were not removed,
> he would derail this case. I saw some "OK, if I need to do multiple
> cases, I will". Please, alter the
> case and repost it (Ken? Margot?).
Okay. Will do.
>
> Its clear that if the "schily" alternate portability layer is destined
> to return as a separate case, you
> should *strongly* consider making this a full case after having been
> accepted by the appropriate
> OpenSolaris community.
>
> - jek3
>
> Joerg Schilling wrote:
>> "James C. McPherson" <James.McPherson at Sun.COM> wrote:
>>
>>
>>
>>>> Well, I remember that a similar case (made for ksh93 integration)
>>>> did already add such a portability layer although (using the same
>>>> rules as for star) the ksh93 case needs those files only for
>>>> private interfaces.
>>>>
>>>> The star integration adds more than private interfaces, note that
>>>> librmt is supposed to be used by ufsdump/ufsrestore too.....
>>>>
>>> As far as I can see, this case does not propose changing
>>> ufsdump/ufsrestore to use librmt. Such changes would be
>>> more suited to a followup case, and should definitely not
>>> be snuck in.
>>>
>>
>> The definitions in /usr/include/schily/ are not only used by star but
>> by many other programs - some of these programs are already on
>> Solaris. They are needed if you like to use interfaces from
>> libschily, libxtermcap, libfind, libdeflt, libparanoia, librmt,
>> libscg/librscg
>>
>> /usr/include/schily/ is a portability framework. It is needed by
>> every program that likes to use one or more of these libraries.
>>
>>
>>>> This is not a new portability layer. It is in use since more than
>>>> 15 years.
>>>>
>>> In use in /opt/schily/.... ? Or in use in /usr/include ?
>>>
>>
>> ????
>>
>>
>>> It appears to be new *to OpenSolaris* and that is what
>>> counts here.
>>>
>>
>> If you like to discuss the interfaces in /usr/include/schily/, you
>> are too late.
>> If you like to influence new interfaces, you need to cooperate when
>> new interfaces are defined. Moving the interfaces now found in
>> /usr/include/schily/
>> to that library has been done 1.5 years ago and it has been discussed
>> on the star integration mailing list and on the ksh93 list. You had
>> the chance to influence this change 1.5 years ago as this change has
>> been done only to make the integration itno OpenSolaris easier.
>>
>> I mentioned several times that there is already /usr/include/ast/
>> which includes
>> interfaces used by a single program (ksh93). Libfind and other
>> libraries offer innovative interfaces used by several programs that
>> are already on OpenSolaris and it is of interest for a lot of other
>> programs. If you believe that /usr/include/schily/ should not appear
>> in OpenSolaris, please remove /usr/include/ast or explain why ARC
>> discussions are not rule based.
>>
>>
>>
>>>> If you like to discuss the internals of librmt, I would encourage
>>>> you to first read the man pages...
>>>>
>>> If you can accept a phased integration as several people have
>>> already suggested, then we don't need to worry so much about
>>> manpages etc and header files for librmt and /usr/include/schily/...
>>>
>>
>> If people ask questions that are answered in the man pages, it is
>> obvious to point to the related man pages. If the issues beyond
>> integrating star at all
>> are not forgotten again, I can live with a phased integration.
>>
>> J?rg
>>
>>
>
