I like to take a step back for a while and think about why a feature is needed in pacman/makepkg (especially from a not Arch perspective as pacman aims to be distro agnostic) So, the issue is sometimes library version mismatches/missingness break a users system. From a pacman/makepkg stand point, how does this occur? In a "stable release" distro, this should never occur. Library differences should only happen between releases which will require a user chaning repos and doing a full -Syu. From experience with Arch, this situation can occur In a rolling release when 1) a user installs a package with "pacman -Sy pkg" and version deps cause other packages to be updated 2) with the use of SyncFirst and non/wrong versioned deps. Case #2 occurred with pacman and was corrected by correcting the versioned dep. Also, it would not have occurred if -Wl,--as-needed was used. Automatic .so deps would have stopped it but so would have correctly versioned deps. So in that situation we already have the tools to deal with this. Case #1 is a case whether this could be useful. But has anyone thought about why this is happening more that it used to? Surely there were lots of people who did a "pacman -Sy pkg" in the past. The answer... excess versioned deps. If we had no versioned deps, only that package specifically being updated would be affected. In general people would not tend to do a "-Sy pkg" with a library and thus the lack of versioned deps only ever caused a minor inconvenience to the user who did the wrong thing. Adding sodeps would just make it difficult for people to do a "pacman -Sy pkg" and those people would end up doing a "-Sd pkg", which would have the same result as no versioned deps. I think a better approach is to have a very few system critical packages providing/depending on the relevant libs and stop over using versioned deps. Allan