On Fri, 16 Apr 2004, Rene Hexel wrote:

> On 16/04/2004, at 6:40 PM, Thomas Klausner wrote:
>
> > I thought major shlib bump was a reason to bump DEPENDS?
> > After all, there is not *.so.200 after the update, so old binary
> > packages _will_ fail. And I don't think that adding such links
> > (.so.200 -> .so.400) is a good idea.
>
>    Neither do I.  But I don't see how bumping depends will help with old
> binary packages.  They would still install against a newer library and
> fail, regardless of whether RECOMMENDED or DEPENDS was bumped.

You've just discovered the well-known and oft-reported flaw of pkgsrc'
wildcard dependency scheme.

A step toward fixing this would be to list needed shared libraries in
the +CONTENTS file using a new key. There ought to be a couple data
items for each key: the needed shared library, and the wildcard
dependency or basename of the package that's likely to provide that
library. The first part could be automatically constructed with the
help of "ldd", but not the second. Maybe the PLIST could just have the
basename, and the "fake-package" target could fill in the wildcard?

Once you have a full collection of such packages to work with,
"pkg_add" could be modified to check, and balk, at least, if a
dependency fails to provide the needed shared library. It would also
become practical to verify the collection of binary packages for
consistency in the face of removals for security reasons and so on.

This is only the third or fourth time this has been brought up, by the
way. The unresolved question was whether you can simply add a new type
of key to the PLIST and have it show up in the +CONTENTS, or whether
"pkg_add" would have to be modified first. In any case, before we add
new key types in earnest, I suggest we also add a "@version" key, so
that "pkg_add" can one day warn on being asked to parse a newer
version of package then it was written to understand.

Frederick