Allan McRae schrieb:
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.
This is a rare corner case. Let's ignore it for now.
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.
It would simply fail or request to update tons of other packages. The problem here is, it fails silently. pacman does not realize that by upgrading dependency A for package B, it makes A incompatible with many other packages. There is no warning and there is no way a user can avoid such situations, other than -Syu'ing. Personally, I recommend to always do a full -Syu before messing with your system at all, but I realize that is not always possible.
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.
If we use fewer versioned deps, we solve a new problem by reverting to an old problem. First of all, I think that adding soname-provides to every package automtically won't hurt anyone (increases package built time slightly) and won't break anything. Even if we never use it, it's nice to have them in pacman -Qi. About versioned dependencies: I am unsure when we should do this: For system-critical packages, definitely, this will simply prevent pacman from breaking those, which is a good thing. For everything else - there's pros and cons, I don't want to complicate our package management too much. One idea is to have a sodepends=(libreadline.so) statement, which would only add a versioned depend on the right libreadline soname, but not on other libraries. Another idea is to implicitly add soname dependencies, but only for libraries owned by packages that are explicitly specified in the depends array (maybe print a warning for the rest). I want to explicitly ask you about the cons for this feature. What do you think is a hard reason NOT to do it?