On Thu, 7 Sep 2000 hubert@feyrer.de wrote:

> On Wed, 6 Sep 2000, Frederick Bruckman wrote:
> > > OK, and what do you suggest then? Tell them that a lib of <newer version>
> > > would be required, judging from information encoded in the (new) "app"
> > > pkg? 
> > 
> > Yes, and also update the DEPENDS in the app pkgsrc (if it isn't fixed
> > already), and delete the app binary package with the broken dependency
> > from the server. [We shouldn't say "app" depends on lib>=1.1 unless
> > "app" built against lib-1.2 is known to work with lib-1.1. I don't
> > want to lay a heavy "burden of proof" on the pkgsrc maintainer though,
> > I just want a way to fix it when someone reports a problem.]
> 
> No. What you propose here is wrong, see all the discussion about
> wildcards. Adding fixed DEPENDS is a bigger source of problems than adding
> wildcard depends by default.

I'm not clear on what I'm being accused of here. In the case described
-- "app" linked against lib-1.2 gives missing symbols when run against
lib-1.1 -- the particular wildcard DEPENDS in "app"'s makefile is
clearly wrong. This could happen if the application's code supplies a
function conditionally on it not being present in the library.

This situation should not come up in the general case, so it's not a
reason to abolish wildcard depends. I'm certainly not asking for that.

> > > And if so, assuming that the information which depends _exactly_ a
> > > pkg was compiled against is only used for user information, how do the
> > > users get this information? Printed automatically? When?
> > 
> > "tar xf pkg-x.tgz '+BUILD_DEPENDS'" is good enough for me. The
> > information is for the maintainers of the binary package collection,
> > not for the user.
> 
> Heh, it might be good enough for you, but it's not really user
> friendly. Some switch needs to be added to pkg_info for this to work, see
> -bB.

That would be OK, too. 


Frederick