Re: svgalib-dummy again
> > 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
> Well, this at least woudn't hurt, I guess. Unless anyone objects
> against this, I'll add this to the svgalib1g I'll upload
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,
> 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?
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .