Jan and Tobbi, Thanks for your comprehensive replies.
I've seen version-dependencies before, for instance with udev, when some packages will break if you're not running at least a particular version. So should Inkscape not require a version-dependency loudmouth, and one for loudmouth on gnutls? In my case Inkscape wouldn't start at all - it's not that I was trying to connect to Jabber server - it just wouldn't run, all I got were the console error messages. Anyway, I'm only a modest user, not a developer, but I'm interested in these issues so thanks for taking the time to explain things to me (even if I must admit I don't understand all the subtleties!) Thanks, Steve On 7/27/06, Jan de Groot <[EMAIL PROTECTED]> wrote: > On Wed, 2006-07-26 at 23:41 +0100, Stephen Wilkinson wrote: > > Thank Tobbi, > > > > I've upgraded loudmouth (and glib2) and now all is fine, without the > > need for symlinked libraries. > > > > I'm trying to understand how this works. > > > > Looking at dependencies of Inkscape I now see that it depends on > > loudmouth which itself depends on gnutls. The newer version of > > loudmouth doesn't "link" (if that's the right term) to > > libgnutls.so.12, in fact that file isn't even part of gnutls > > (according to the file list). So it was loudmouth looking for the > > wrong library. > > > > Should the installation/upgrade of Inkscape not require (and force) an > > upgrade of loudmouth and consequently gnutls to ensure that all the > > expected files are there? Or is there a loophole in the pacman system > > which means that such dependency problems can occur? > > When we updated GNUTLS to 1.4.0, we recompiled every package that > requires GNUTLS and put versioned dependencies on it. We didn't > recompile packages that depend on these packages, as they pick up the > new GNUTLS automatically as long as they weren't linked to it > explicitly. > > The problem we have is that we keep the packages the same, no matter > what they provide. GNUTLS can contain any version with any .so.x > versioned library. On a distribution like debian, they use libgnutls10, > libgnutls12, libgnutls13, etc, so it's very easy for them to depend on a > given version of the package. We can depend on gnutls>=1.4.0, but > somehow we can't put up versioned conflicts. We would have to make > version ranges with expectations from the future to get this as solid as > debian does it. Another way is to use the dependency checking that RPM > does, with the library filename provides. I don't like this though, as > it is the base of "Dependency hell" that you hear about all the time > when people are complaining about RPM. > > The best solution is, that when you get updates of important libs, > always run pacman -Syu against a recent mirror. When important libs are > bumped, these are announced on the frontpage, which happened to be > gnutls, openssl and db the last time. > > > _______________________________________________ > arch mailing list > [email protected] > http://www.archlinux.org/mailman/listinfo/arch > _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
