[arch-dev-public] How the use of "provides" can damage the dependency tree
Hi devs, I just had an interesting case where a missing dependency cam be unnoticed for a long time. I was told that KDE from kde-unstable could not start due to a missing lib: libxdamage. Neither namcap or anyone else did found this missing dep. And here was the solution: libxdamage is needed by libgl which in turn is needed by mesa ->qt->kdelibs etc.. But if you have nvidia-utils installed which provides libgl but does not depend on libxdamage or libxxf86vm you'll end up with a broken dependency tree. What do we learn by this? The use of provides can be dangerous when the providers have different deps. I wonder if we have more such problems. Pierre -- Pierre Schmitz, http://users.archlinux.de/~pierre
Pierre Schmitz schrieb:
What do we learn by this? The use of provides can be dangerous when the providers have different deps. I wonder if we have more such problems.
That's why namcap should use direct link-level dependencies using readelf and not rely on the fact that a dependency already provides the library in question.
On Fri, Jul 24, 2009 at 1:21 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Pierre Schmitz schrieb:
What do we learn by this? The use of provides can be dangerous when the providers have different deps. I wonder if we have more such problems.
That's why namcap should use direct link-level dependencies using readelf and not rely on the fact that a dependency already provides the library in question.
Actually, this would probably help us in a lot of ways - it'd make finding deps for rebuilds easier
On Fri, Jul 24, 2009 at 21:23, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Fri, Jul 24, 2009 at 1:21 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Pierre Schmitz schrieb:
What do we learn by this? The use of provides can be dangerous when the providers have different deps. I wonder if we have more such problems.
That's why namcap should use direct link-level dependencies using readelf and not rely on the fact that a dependency already provides the library in question.
Actually, this would probably help us in a lot of ways - it'd make finding deps for rebuilds easier
I completely agree here. Could we please change our default policy to always include direct dependencies (checked from readelf output) even if another dependency already pulls them? -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
On Fri, Jul 24, 2009 at 21:23, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Fri, Jul 24, 2009 at 1:21 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Pierre Schmitz schrieb:
What do we learn by this? The use of provides can be dangerous when the providers have different deps. I wonder if we have more such problems.
That's why namcap should use direct link-level dependencies using readelf and not rely on the fact that a dependency already provides the library in question.
Actually, this would probably help us in a lot of ways - it'd make finding deps for rebuilds easier
I completely agree here. Could we please change our default policy to always include direct dependencies (checked from readelf output) even if another dependency already pulls them?
So listing every single package that contains a library that is being linked to... Apart from being annoying to maintain (especially if we add versioning to them as well), that would really increase the amount of work pacman has to do in dependency checking. e.g. for subversion there is currently two dependencies, but even only considering /usr/bin/svn there would be 10x more than that. Allan
On Sun, Aug 2, 2009 at 12:11, Allan McRae<allan@archlinux.org> wrote:
Roman Kyrylych wrote:
Could we please change our default policy to always include direct dependencies (checked from readelf output) even if another dependency already pulls them?
So listing every single package that contains a library that is being linked to... Apart from being annoying to maintain (especially if we add versioning to them as well), that would really increase the amount of work pacman has to do in dependency checking. e.g. for subversion there is currently two dependencies, but even only considering /usr/bin/svn there would be 10x more than that.
Okay, then how we currently check that subversion needs to be rebuilt on db or heimdal soname bump? -- Roman Kyrylych (Роман Кирилич)
Am Sonntag 02 August 2009 11:26:51 schrieb Roman Kyrylych:
Okay, then how we currently check that subversion needs to be rebuilt on db or heimdal soname bump?
That's where the link database would help a lot. -- Pierre Schmitz, http://users.archlinux.de/~pierre
Pierre Schmitz wrote:
Am Sonntag 02 August 2009 11:26:51 schrieb Roman Kyrylych:
Okay, then how we currently check that subversion needs to be rebuilt on db or heimdal soname bump?
That's where the link database would help a lot.
Or the rebuild script I have posted which scans all the packages in the repos in a few minutes. Allan
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler