consider this edge case: - system is built with USE=-tinfo - USE=tinfo is added and ncurses is rebuilt - portage merges libncurses.so from $D to $ROOT before libtinfo.so - for a short period of time, all programs that use ncurses fail (like bash): /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory - once libtinfo.so is merged, libncurses.so works, as do all other programs i use tinfo as an easy example, but it is not the only one. any time a package has multiple libraries and links against themselves we can see it. another example w/ncurses: if you upgrade from ncurses-5.0 to ncurses-5.9, while the SONAME is unchanged (so it'll be backwards compatible), there might be new symbols added that the ncurses programs need. so this case will fail: - portage merges /usr/bin/tput - program runs tput which fails because libncurses.so.5 is the old one and tput wants some new symbol - portage merges /lib/libncurses.so.5 - /usr/bin/tput works again since it is impossible to make this perfect w/out filesystem level support (i.e. transactions), we can at least improve the merge algorithm: - update all libraries before programs - update libraries using DT_NEEDED dependency information - e.g. libpanel.so needs libncurses.so which needs libtinfo.so, so update in reverse order: libtinfo.so first, then libncurses.so, then libpanel.so - once all libraries have merged, update the programs - e.g. /usr/bin/tic and such we can define "is a program" by the metric "it's an ELF and has an interp" with the caveat than any library that declares that program as DT_NEEDED promotes it to a library. all libraries that lack DT_NEEDED tags for files to be merged should be merged first. there could be a possible dependency between the data files and the libraries/programs, but let's not worry about that for now as it's much harder to determine the right order.
