> > dpkg's current dependency mechanism doesn't allow it to be a > > substitute for svgalib, because that is a shared lib and so all > > dependencies on it are versioned dependencies (coming from the .shlibs > > file). > > Well, more to the point: when package foo "Depends" on a particular version > of package bar, dpkg ignores all packages that provides: bar. > (It'll only look at the exact package bar, and it's version).
Clear. What I meant with "because it's a shared lib" is that usually all dependencies on a shlib are versioned dependencies, because they come from the .shlibs file. > Well, it isn't the library stuff that goes wrong, it's the specific > versions that cause dpkg to ignore the Provides: packages. That's what I'm saying, isn't it? > Only if the *dpending* packages depends: on a particular version of > the shared lib package. Usually, this isn't the case (the soname of > the library is encoded in the package name, so a package could just > depends: "libfoo272", with 272 the soname of libfoo. But yes, with > the current shlibs files, they will always depend on a particular > version of the library, and it will always go wrong. Yup, that's it. AFAICR, the (>= x.y.z) there has been introduced to avoid that people use too-old shlibs at runtime, which is basically a good thing. > Well, this at least woudn't hurt, I guess. Unless anyone objects > against this, I'll add this to the svgalib1g I'll upload > tonight/tomorrow. That would be fine! Would at least fix the problem for packages that are recompiled with the new glibc version of svgalib. > They have to be rebuilt for libc6 anyway. So that's no problem. You're right here. > I strongly prefer method 1. I really think dpkg should be improved, Me too... > but as that doesn't seem to happen any time soon, I don't think > method 2 will hurt in the mean time. Ok. Any other opinions? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .