From owner-freebsd-questions@FreeBSD.ORG Sat Feb 14 23:25:13 2015 Return-Path: Delivered-To: freebsd-questions@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 4A097E26 for ; Sat, 14 Feb 2015 23:25:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01263390 for ; Sat, 14 Feb 2015 23:25:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YMm59-0002Pj-Bd for freebsd-questions@freebsd.org; Sun, 15 Feb 2015 00:25:03 +0100 Received: from 63-245-179-205.ip.mtelco.net ([63-245-179-205.ip.mtelco.net]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Feb 2015 00:25:03 +0100 Received: from jgoerzen by 63-245-179-205.ip.mtelco.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Feb 2015 00:25:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: John Goerzen Subject: Re: Ports/Packages and release engineering Date: Sat, 14 Feb 2015 23:20:53 +0000 (UTC) Lines: 52 Message-ID: References: <54DF89BE.6010005@complete.org> <54DFA962.2010509@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 63.245.179.205 (Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.4.0) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:25:13 -0000 Matthew Seaman infracaninophile.co.uk> writes: > > On 14/02/2015 17:45, John Goerzen wrote: > Configuration files are *not* owned by ports per-se, so they aren't > necessarily removed or modified when a port is deleted or updated. > Instead the port owns various sample configuration files, which > generally have the same name as the actual config with '.sample' > appended (other naming variations exist, but '.sample' is by far the > commonest.) These the port will replace at will. When a port is > installed the first time then the sample config file is copied to the > real config file name. When the port is removed or upgraded, then the > config file is removed if and only if it is identical to the sample file. > > There isn't a capacity for doing a three-way merge in the ports at the > moment, so if the upstream has made incompatible changes to the config > file format the administrator will have to merge those manually. This > is fortunately a fairly rare event. 3-way merge capability has been > added to pkg(8) but that capability hasn't been applied to the ports yet. Matthew, thank you for your very helpful reply. A few small outstanding questions: I actually expect to use pkg(8) rather than ports almost all of the time. So it sounds nice that pkg(8) can do this, but I am confused about the relation between ports and pkg. I see some rather contradictory information out there, and wonder if this changed in FreeBSD 9 or 10? I see some people saying that a person always needs to tell the ports system to register with pkg, but then I don't see anything in the Handbook saying to do that these days. So if a port only supplies a .sample, on what basis would pkg do a 3-way merge, since nobody is likely to modify .sample directly? > Reinstalling all your ports on a major version upgrade is still a > requirement, yes. But it is something that may not remain so for a > great deal of time longer, given the advent of symbol versioning in the > base system shared libraries. While you can still *run* a port > installed for, say, 9.3-RELEASE once you've upgraded to 10.1-RELEASE, > until everything in the base system has appropriate symbol versioning > applied you'll very quickly get into a pickle if you try and update some > ports selectively: effectively you would end up with one binary trying > to dynamically link against two or more different versions of the same > shared library: something that always ends in tears. Ah. OK. So is there really that much churn in base system libraries? It's not necessarily an issue for me, but just a surprise; I'm used to systems where most binaries that are a decade old still work fine on modern systems. Thanks again, John