Date:        Sun, 25 Jan 2004 19:11:26 +0000
    From:        "Johnny C. Lam" <jlam@netbsd.org>
    Message-ID:  <20040125191126.GA8806@NetBSD.org>

  | It doesn't require two separate versions.  If a package's DEPENDS
  | contains:
  | 
  | 	zlib>=1.1.4nb1:../../devel/zlib
  | 	zlib>=1.2.1:../../devel/zlib
  | 
  | then it simply states that any zlib that is used as a dependency for
  | the package must satisfy _both_ of the restrictions listed in DEPENDS.

But why would a package's depends say that?   Surely that would be a
bug, it needs only the 2nd of those two, doesn't it?

  | This is merely some bookkeeping issue to make sure that we never
  | downgrade a dependency by explicitly setting a BUILDLINK_DEPENDS.<pkg>
  | line in some buildlink3.mk file somewhere.

But I don't think there should be such a setting, anywhere.

Note, I have no objection to this actual change, that is, I don't think
it is incorrect or anything, I just don't think it should be necessary
if everything was functioning in a sane way.

  | No, we do not increase them whenever the package is updated.

I know that, and I didn't say that you did.   What I said was that
a package cannot possibly know which version of itself some other
package depends upon, so the buildlinkN.mk file shouldn't be saying
anything at all.

  | The dependency version in the buildlink*.mk files are only changed whenever
  | one of the following two criteria are satisfied:
  | 
  |     (1) a security fix is added to a library, or
  |     (2) the major number of a shared library has increased.

But why should my package care about either of those?   I don't care what
major library version it is, that's irrelevant to me.   I only care about
security fixes if they apply to some function that I'm using, otherwise
they're irrelevant.   You cannot possibly know either.

  | The dependency versions are again bookkeeping issues, this time to ensure
  | that binary packages with wildcard dependencies will work correctly.

Binary packages shouldn't have wildcard dependencies - a binary package
gets compiled against some particular version of its dependencies, it should
record which particular version that is, in any case it cares at all
(there probably needs to be two different kinds of dependencies, one for
"I need perl installed", and one for "I am using version X of this library").

Quentin Garnier <netbsd@quatriemek.com> said:
  | Correct me if I'm wrong, but it's not about binary packages here.

I know, pkgsrc was what I was talking about - though a lot of this is
clearly being done to make a particular model of binary packages work.

netbsd@quatriemek.com said:
  | With the ?= assignment, package A could assign BL_DEPENDS.xxx xxx>=2, and
  | then package B (in the order of bl.mk inclusion) assign BL_DEPENDS.xxx
  | xxx>=1

package A should never see, nor care about package B's depends - if A depends
upon B, then B exists when A is built/installed, and all of B's dependencies
must have been satisfied already, there's no need to go and do them all again.
This is true for both pkgsrc and binary packages.

The only thing that matters are the things A itself directly depends upon,
all the rest is taken care of - and for that, there's just one version
required of each dependency.

These problems all come about by including the BUILDLINK_DEPENDS lines in
every buildlink.mk file - if there were none in any of those files, only
in the various pkgsrc Makefiles, none of these problems would be occurring.

Next, with this new world order, how do I explicitly override the
BUILDLINK_DEPENDS line in a buildlink3.mk file?   I do that quite often
in practice (or did, until now).

That is, some very popular package A, was upgraded for some reason that
doesn't concern me, so I ignore the update (perhaps a bug for some architecture
that I don't use was fixed, or it was made faster, or ...).   In any case
assume that what happened was one of those things which does cause its
BUILDLILNK_DEPENDS to get updated (or did, correctly or not).

Then some package (B) is upgraded for a reason I do care about, perhaps a
security fix, or similar.   This one I want to upgrade.

That's fine, I go upgrade B, which requires me to rebuild C, which
depends upon B.   I'm not real happy about the need for this, as I
believe that B should really just be able to be upgraded without touching C,
but that's OK, I know how pkgsrc likes to be safe, so I go ahead and delete
C, and then upgrade B.   Fine.

Now I come to recompile C against the new B, only to find that C is
now demanding the new A be installed.   C was working just fine with
the old A 15 minutes ago, it would work fine with the old A again if
pkgsrc would compile it that way - but it won't.   I could upgrade A,
but that one turns out to require me to delete and reinstall almost
everything.   No way.   So, instead, I just get C's makefile, and
add a BUILDLINK_DEPENDS.A=old-version and start again.   C is now happy
to use the old version of A (C's makefile should have always had such a
line in it IMNSHO).

What's the method to accomplish this in the new scheme?

kre