I do not quite understand why a BIND upgrade needs to touch soo much.

Garrett Wollman wollman at hergotha.csail.mit.edu
Mon Dec 15 23:05:31 UTC 2014


In article
<CAKFCL4UAzSXKoB+Jo=a=nv+WaejcEXoDh2-yMauZxf_Dd8J4Eg at mail.gmail.com>, allbery.b at gmail.com writes:
>On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen <wjw at digiware.nl>
>wrote:
>>
>> Yup, more than true in the ultimate case.
>> Although 'portupgrade bind99' in this case did not require any other
>> packages to be upgraded too.
>>
>
>Hm; I'd expect it to notice the new gettext and build that as well, since
>the new bind might depend on changes in it (it has no way of knowing that
>in this case it's safe).

No, portupgrade has no concern over whether there's a new gettext
unless you tell it to upgrade dependencies recursively -- it doesn't
look at the gettext port at all otherwise.  The dependencies in ports
are on the files that are installed (usually shared libraries or
pkgconf data files): if the required files already exist, the ports
framework doesn't look at the dependency.  (If the required files
hadn't already existed, then in this case they'd probably fall afoul
of CONFLICTS checking when attempting to install the dependency and
the portupgrade would fail.)  Most of the time this would work, but it
would fail in interesting ways and leave you unsure as to whether your
set of installed packages was actually self-consistent.

>This comes of prebuilt packages. In theory, a poudriere setup could be
>managed so that you updated only the bind99 Makefile. If you're relying on
>the standard packages, or updating a poudriere ports tree without checking
>/usr/ports/UPDATING first, you have no way to limit the update and get a
>bind99 package built against the old gettext; you have little choice but to
>upgrade everything.

It's a trade-off, of course.  Some other operating systems have armies
of volunteers to manage old versions of packages, backporting security
fixes and whatnot; in FreeBSD we have at best a brigade, not an army,
and have historically chosen to always build self-consistent package
sets and only support the versions supported the the upstream
developers.  This is sadly why a number of ISVs have gone on a
"self-contained packaging" trip, so if you install commercial
software, you may no longer know how many unpatched copies of the JRE
(for example) (or Python or FreeType) you have sitting around buried
in some application's directory tree.

That said, I do think there's a bug in pkg 1.4's dependency solver.  I
upgraded my home workstation over the weekend, and it wanted to
uninstall a number of packages[1] that did not have any plausible
connection to the things that changed.  After allowing the upgrade to
complete, I reinstalled the uninstalled packages with no issues.

-GAWollman

[1] inkscape was one; I don't recall the others.


More information about the freebsd-stable mailing list