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
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: