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
I don't have any of those libraries installed on my SXCE build 83 system. They are not required for any currently integrated part of OpenSolaris. In the future, I'm sure they will be required, but today they are not. Paper tigers don't help your argument. Other people have asked you why /usr/include/schily contains such files as param.h and utypes.h. Since we already ship the file /usr/include/sys/param.h, what benefit does having a private copy in /usr/include/schily serve? > /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. Again, that is not actually the point. What is the point here is that - we don't need to provide /usr/include/schily/.... in order to deliver librmt, star and friends. Insisting on delivering these interfaces makes them a roadblock to getting your code integrated. You have a Sun engineer willing and able to help you, and a community group which (as far as I can see) is more than happy to help as well, and you are insisting that Interfaces (note the "I") be delivered when they are not actually required for Joe Random User to make use of star et al. We, the OpenSolaris community, do not need /usr/include/schily *right now* in order to make use of star. The horse is dead, stop beating it. > 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. I'm not saying that /usr/include/schily should not appear in OpenSolaris. What I am saying is that *FOR THIS CASE* the /usr/include/schily file list *appears to be* an impediment to getting star et al integrated. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
