Am Mittwoch, 3. Februar 2010 10:27:43 schrieb Thomas Bächler:
I get the feeling that you are desperately looking for reason to not implement a feature that is obviously a necesity.
I like the idea of adding sodeps and soprovides. Ideally they should be even added to the db files so tools could use this information to create a rebuild list or a global dependency check. What I really don't like is magically adding them to existing depends and provide arrays. They should stay in their own arrays. The point where you added the soname-prefix should have told you that you are probably doing some kind of evil hack here. Here are my arguments why adding those sodeps to existing depends is bad; the idea in general is not: In addition to Allan's arguments one has to see that theses sodeps just cannot be 100% safe. And even if they would work for 90% of our packages the left 10% would possibly break the other due the nature of a dependency tree. E.g. you are just providing the soname of any file that is included in a package. But you have no idea if other apps will load this library at runtime or if the linker does pick it up. For example there are file with the same so names in different directories (I think I have seen same names in kdelibs3 and kdelibs). Some apps bring their own version of a lib like jre has its own libjpeg. Sure, you could disable soprovides for known "broken" packages. But let's face it: we will have such packages in our repos that break everything else due to such false provides and deps; especially if the maintainer does not see what happens here and has no real control over it. My suggestion is: implement this as separete sodeps and soprovides arrays without the soname-prefix and let's write tools to make use of it. And maybe we could teach pacman using those information, too. E.g. it could issue a warning if it found a broken sodep. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre