On Mon, Aug 27, 2007 at 08:59:06AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Baldwin <[EMAIL PROTECTED]> writes: > > : Yar's changes should go in and before BETA1, but we don't need any compat > : hacks because the compat would be for users that we don't provide compat > : for. > > ALL of Yar's changes should go in, including the versioned symbols. > Since the consequences of this ABI breakage are trivial to mitigate > with symbol versioning, we should do so. We need a dry-run at it to > make sure there are no problems in the process. We also should not > force all our testers right now to go through significant pain and > suffering. They are much less likely to upgrade and continue to test > out new versions of current. Rebuilding all the ports (since it is > hard to know which ones use fts) is hard and time-consuming (even on > my fast machines it takes days to rebuild everything exclusive of > ooo).
Although I can appreciate the arguments of Daniel and John now, [thank you John! :-)], this is also a very valid point to consider. I hate to mention it, but symbol versioning appeared literally non-functional due to a bug in the map-generating script when I tried to use it for the first time in the course of the fts(3) hustle. > In short, I think this is the easiest solution to the build problems > that the change will cause given the set of users that are presently > using the head of the tree. Hacking the build system to make the > incompatible change is dangerous and may break other upgrade paths > that are working. Giving users explicit instructions for jumping the > gap would fix the intallworld case, but would still force users to > rebuild all their ports. Adding the versioned symbols introduces a > tiny bit of cruft in the purity of the ABI, but solves the > installworld problem AND the rebuilding the ports problem. Are there > other REAL solutions to the problem I've not considered? I hope I've found a clean way to overcome the problem in our build system. The problem stemmed from using basic tools from the old, pre-installworld system during installworld. The tools were copied just in case to a scratch directory, so it isn't hard to install the newly built versions of the same tools there instead and make them load the new shared libraries available under ${WORLDTMP}. The trick depends on the running kernel being able to run both old and new code, but it's a well-known requirement for installworld over the live system. I'm going to post the patch for review soon. -- Yar _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"