DJ Lucas wrote: > I can however, immediately see on > the other side of the argument, nss, and in turn, xulrunner have to be > rebuilt anyway if a new version of nspr comes out with security > fixes....following that logic, we shouldn't even have separate > nss/nspr...only separate out xulrunner. > I should have qualified that better...*after* Thunderbird and Seamonkey catch up to the 3.0 series. I think that we should seriously consider dropping nss/nspr standalone once the other products that we support catch up and can use a system installed xulrunner.
I do believe that it is a reasonable expectation that a new release of Firefox will happen if a security bug is fixed in any of the standalone packages because they are included in the binary distributions. At very least a warning would need to be added to the nss page instructing people to use the Firefox internal copy if you plan to build any Mozilla products...to save yourself from rebuilding multiple packages. I don't have any idea if any of the above is true for the 2x line as I don't have any build logs handy to see how the packages are linking to the nss/nspr libs. I also don't know about other products that use the nss libs. George had previously mentioned Pidgin to me in an off-list message about the include flags in the version of nss-config that I had suggested. OOo and OpenJDK are going to be fun again too. Anyway, I'm going to have to bow out for a while...back to the LFS base for me because of the recent reports about /tools showing up in the final system. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
