Some people have expressed annoyance at the new behavior of the ports
building system. Specifically, the fact that if your ports tree is out-of-sync
with the installed system, you might run into trouble.

But the new behavior is here to stay, because it's WAYS more consistent
than it used to be.

Historically, the ports tree solves dependencies during build time by matching
stuff against installed packages. Then, at the end of build, it creates a
package which records dependencies.

*however* the dependencies were half-taken from the ports tree, and 
half-taken from installed packages.

They can't be entirely taken from installed packages, here's why: if you build
a package that depends on ghostscript, it often won't matter whether you have
ghostscript-- or ghoscript--no_x11 installed. *but* if you take the deps from
the installed package, then you end up with "non-reproduceable" builds: one
package built somewhere will have ghostscript-- in its depends line, the other
one will have ghoscript--no_x11 in its depends line.

Thus, package builds have filled the @depend line with info from the ports tree
for quite a few years.

This has become *ways* more vital recently, because it is part of the info
that's used during updates: to determine whether to update something or not,
pkg_add first looks at the pkgname proper, and then, if that didn't change, it
*looks at the whole signature*: all dependencies it was built from. If those,
for some reason, are non-comparable, then it will whine (it means a dependency
changed, and nobody bumped the REVISION, which is bad). So, if you have
foo-1.0 that depends on ghostscript-- and foo-1.0 that depends on 
ghostscript--no_x11, guess what ? those are non-comparable...

This is why PLIST_DB was tweaked to take this into account, so that 
bulk-builders would notice when this stuff happens.

For instance:
Create /home/ports/packages/amd64/all/mplayer-20110309p5.tgz
/home/ports/plist/amd64/mplayer-20110309p5 was updated
graphics/ffmpeg:ffmpeg->=20110408:ffmpeg-20110408 -> 
graphics/ffmpeg:ffmpeg->=20110408:ffmpeg-20110408p1
avcodec.15.1 -> avcodec.16.0


But now, if we take @wantlib lines from installed stuff, we're asking for 
trouble, since the @depend lines come from the ports tree !

Hence the recent change, which does check that installed libraries do match
what's in the ports tree, in order to produce correct depend lines AND wantlib
lines.  Otherwise, you could end up with packages *that would be impossible to
install on somebody else's machine*.

(and there are probably bordeline cases where the dependency tree says something
and the installation tree something else, like when wantlib are not really
reachable the correct way).

One unfortunate side-effect is that this stuff is a bit slow... which is partly
why I shoved it in so that people could give me enough details to make it
faster (okay, it's not perfect yet, but we are getting there).  It should be
possible to waive the check when you're actually polishing a port, and building
and rebuilding a package...

But the primary goal is still to build binary packages that work flawlessly
on a user's machine, without the need for him to rebuild stuff from the source
tree. All the recent checks in bsd.port.mk and pkg_create and PLIST_DB were
specifically added to facilitate this.

The second benefit from that change is that more stuff is amenable to 
introspection: now, make print-plist-with-depends gets all its info from
the ports tree and should always work, irregardless of how much you *don't*
have installed. Yes, this will help lib-depends-check, and it should already
make out-of-date checks ways more accurate, as they can now properly compare
installed libraries with libraries in the ports tree.

Reply via email to