On Mon, 2011-07-25 at 14:04 -0500, Mark Hatle wrote: > As for maintenance, I see this as not terribly complex once you understand > what > and why the patches exist. Except for the two? headers that I hand merged, > everything else is obvious once you run a diff between the stock i386 and > x86_64 > versions. There is no intent for "original content" to be in this patch.
The thing about maintenance is that this is a big patch which touches a lot of files and, although it might be obvious to you what it's doing and how the contents are generated, it is not necessarily going to be so obvious to the lucky soul who gets to update the eglibc recipe to a new version. If the intent of the patch is that (in most cases) the x86-64 headers are just being copied on top of the i386 ones, it would be better expressed as exactly that, i.e. a series of "cp" commands. Doing it as a patch is fragile since if the i386 header changes then the patch will fail to apply, whereas if the x86-64 header changes then the patch will become stale and you will end up with different contents again. The more files are touched by the patch, the greater the likelihood that at least one of them will have a problem for any given upgrade. Of course, doing it with "cp" does bring the opposite risk: that a necessary change to the i386 headers might be lost if the x86-64 ones are not also updated. This seems like a smaller risk but perhaps not a completely negligible one. And, given that there is at least one header (ie syscall.h) that can't be merged, I am still tempted to say that the path of least resistance is simply to install the whole lot into parallel directories and add them to the front of the compiler search path. Having separate /usr/include/32 and /usr/include/64 trees would also avoid the need for that interstitial header and the licensing imbroglio that it seems to be causing. p. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
