From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 23:05:31 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 986614F0 for ; Mon, 15 Dec 2014 23:05:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6840FA06 for ; Mon, 15 Dec 2014 23:05:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id sBFN5SJU010941; Mon, 15 Dec 2014 18:05:28 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id sBFN5SPp010940; Mon, 15 Dec 2014 18:05:28 -0500 (EST) (envelope-from wollman) Date: Mon, 15 Dec 2014 18:05:28 -0500 (EST) From: Garrett Wollman Message-Id: <201412152305.sBFN5SPp010940@hergotha.csail.mit.edu> To: allbery.b@gmail.com Subject: Re: I do not quite understand why a BIND upgrade needs to touch soo much. References: <548F4F62.4020308@digiware.nl> <548F5C6F.7040309@digiware.nl> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 15 Dec 2014 18:05:28 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:05:31 -0000 In article , allbery.b@gmail.com writes: >On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen >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.