[pacman-dev] implement .so dependencies?

[Pierre Schmitz]

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