Shawn Walker wrote: > Nicolas Williams wrote: >> On Thu, Jul 23, 2009 at 09:07:53PM -0700, Garrett D'Amore wrote: >>> I agree with all of your points. >>> >>> However, we've already established a precedent in many other cases >>> that FOSS cases can integrate without necessarily taking the same >>> steps that we would require of software developed internally. >> >> But surely there are limits. Having the GNU Pth library on the system >> for other apps to link with is bad. Using the GNU Pth library in GPG is >> less bad. Why not just require that the i-team at least not deliver Pth >> compilation links, or, better, statically link Pth into GPG? > > I'm sure there are other bits of FOSS software that use the GNU Pth > library. While I too would like to see software we ship use the better > threading library, isn't at least justifiable that GNU Pth be shipped to > make it easier to compile and use FOSS that is not provided by Sun? > > Cheers,
Yes, thank you, that is my position as well. There are plenty of FOSS packages already delivered that could benefit from being modified to take full advantage of native Solaris code. It is unreasonable to burden the teams that want to bring FOSS code to Solaris to also put in additional effort to fully "Solaris-ize" the code in question. If integrating into ON, then the argument is stronger, but for SFW packages ideally we like to just drop in the tarballs from the upstream community and apply a minimal amount of changes to get it to compile and work. The overall goal is to attract more FOSS development on Solaris. If we try to redesign every package to fit our preferred model, the level of interest will fall off significantly both internally and externally. If someone in the future wants to deliver a project that is written from scratch and they want to use Pth instead of the native thread libraries, there are architectural reviews, code reviews, and design reviews that should hopefully steer that team away from Pth in favor of native libraries. -Wyllys
