That is how we normally do it (E.G. let the big versions "win" if both are enabled). What would you suggest we do instead?

(In reply to comment #1)
> That is how we normally do it (E.G. let the big versions "win" if both are
> enabled). What would you suggest we do instead?

The bigger version winning is fine and to be expected.  What surprised me and took me a couple of hours to figure out was that busybox itself and not just one of its symlinks was overwritten.  More specifically, here is what I think happened in my case:

When busybox was built and installed, it was installed as /bin/busybox and many symlinks including /sbin/init and /usr/sbin/flashcp were installed pointing to /bin/busybox.

When mtd-utils was built and installed, flashcp was installed as /usr/sbin/flashcp, but because a symlink already existed for busybox, the symlink was followed and flashcp was actually installed as /bin/busybox overwriting the real busybox in the process

When I booted the resulting rootfs, the kernel executed /sbin/init which should have been busybox but was flashcp instead.  flashcp then complained about bad command line arguments and exited cusing the kernel to panic because init exited.

I'm new to buildroot, so if this is how things are supposed to work, I'll learn to live with it.  In an ideal world, the config system would prevent such overlaps in functionality.  I realize the large number of busybox options makes that too tedious to be practical.  

Perhaps a reasonable middle solution is to make sure the installation of other packages don't follow symlinks and clobber busybox.  Alternately, perhaps the busybox installation can be deferred until after the other packages and its symlink creation changed to not clobber existing files.

Ahh, ok - That's something completely else. I have updated the mtd-utils package in git to 1.3.1, and fixed the target install to use 'install', which doesn't follow symlinks.

Thanks.  I should have been clearer about the seriousness of clobbering busybox the way it did.