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?).
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 > >
