In article <20041009161202.GA1634@panix.com>,
	tls@rek.tjls.com (Thor Lancelot Simon) writes:
> 
> There are two related problems here.
> 
> The first is that package Makefiles are often updated to require whatever
> version of a dependency the updating developer happens to be working with,
> even though there's no difference that would actually make the package,
> rebuilt from source with the older version of the dependency, not work.
> 
> Obviously getting this right for the *binary* case is hard but we could
> be a little more careful to not cause needless dependency rebuilds in the
> source case.

But, but..., there is no "source case"!  How can you know a user won't
do a "make package", then try to install the package later on the same
machine (a downgrade for a regression, perhaps), or on an another
machine?  Even if he doesn't do "make package", perhaps he would use
"pkg_tarup" in the future, then have all the same issues.

That said, there's already a solution in place for "source only" users.
See the part about "/RECOMMENDED" in "Packages.txt".  With that, you
can build packages all day long with the wrong -- that is, "permissive",
dependencies.
 
> A related problem, though, is that sometimes the opposite mistake is
> made -- look at the ap_perl package, where the binary package gets only,
> say, perl5 >= perl5.8.3 built into it, because that's what the Makefile
> had; but in fact, the built binary will depend on the later version
> that it was actually linked with, so when you install it on a system
> that _actually_ has 5.8.3, it doesn't work.
> 
> I think it would make sense to be a little more careful about recording
> higher dependency versions than necessary in Makefiles, but also to record
> the dependency in the *built binary package* as the actual version linked
> with, or higher, not the dependency version given in the Makefile.  This
> would kill two annoying upgrade problems in one shot, no?

This isn't exactly what you're asking for, but we already record the
actual version built against in the "+CONTENTS" file (as @blddep), and
"pkg_add" will even prefer that version over the latest version, if it's
available.[1]

Doing more, as in cranking the dependency automatically, would tend to
put off binary package users in the same way that unnecessary cranking
puts off source users.  Consider the case where a developer builds a
newly committed package against, say, the latest "glib1", and uploads
it to where there's already a body of packages against the older
"glib1".[2]  A user might not want to upgrade "glib1", and he shouldn't
have to -- "glib1" is fully baked, and suffers only tweaks to the
${PKG_REVISION}, no more ABI changes.

I dare say, this is all mostly hypothetical, since there are no binary
packages users (not practically -- not for long, anyway), but for NetBSD
2.0, it would be nice if the binary package collection on ftp.netbsd.org
were actually useable, and it may yet be.

Frederick


[1] I'm not sure that's actually a good idea.  It's a quick and happy
fix for a user who installs exactly one package plus its dependencies,
but it doesn't scale well, as when, for example, a second package
needs a newer version of one of the dependencies.  I, myself, requested
encoding the as-built dependencies in the package for various reasons,
but I never expected "pkg_add" to make trivial use of them.

[2] Declaring that we must now only upload packages that are built
against the latest branch doesn't change the fundamental issue, it
only defers it until the next branch is tagged.