From owner-freebsd-questions@FreeBSD.ORG Sun Feb 15 20:04:00 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36DD254C for ; Sun, 15 Feb 2015 20:04:00 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B29E3FF5 for ; Sun, 15 Feb 2015 20:03:59 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.100]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t1FK3qqA048757 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 15 Feb 2015 20:03:52 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t1FK3qqA048757 Authentication-Results: smtp.infracaninophile.co.uk/t1FK3qqA048757; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <54E0FB9C.1090706@FreeBSD.org> Date: Sun, 15 Feb 2015 20:03:40 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Ports/Packages and release engineering References: <54DF89BE.6010005@complete.org> <54DFA962.2010509@infracaninophile.co.uk> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qL9Sr04p1jH4uFEOEaKOf005OvtHtr2KV" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk 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: Sun, 15 Feb 2015 20:04:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qL9Sr04p1jH4uFEOEaKOf005OvtHtr2KV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/02/2015 23:20, John Goerzen wrote: > Matthew Seaman infracaninophile.co.uk> writes: >=20 >> >> On 14/02/2015 17:45, John Goerzen wrote: > I actually expect to use pkg(8) rather than ports almost all of the tim= e.=20 > 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 inform= ation > out there, and wonder if this changed in FreeBSD 9 or 10? I see some p= eople > 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 th= ese days. pkg(8) is the only game in town now, and has been since last april (IIRC). All supported versions of FreeBSD use pkg(8). There's a lot of historical information floating around from the transition period when lots of people were still running pkg_tools based systems and many of them were needing to convert. You'ld have to be running something pretty seriously out of date to still be in that position today though. As for ports and pkg: it's easy really. ports are a set of instructions for building 3rd party software pkg(8) is a tool for managing collections of files, commonly used for handling the results of ports compilations. All the binary packages currently available are the results of ports compilations, be that ones done on the central package building systems, or ones done locally on an individual system via tools like portmaster(1) or portmanager(1). > So if a port only supplies a .sample, on what basis would pkg do a 3-wa= y > merge, since nobody is likely to modify .sample directly? At the moment, pkg(8) doesn't do any 3-way merging. That's something that is currently under development. > 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 syste= ms > where most binaries that are a decade old still work fine on modern sys= tems. The promise is that a binary compiled on the earliest release from any major branch will be forward compatible with any subsequent releases from that same major branch. (So something compiled under 9.0 will work on 9.3, but something compiled on 9.3 will not necessarily work on 9.0). Yes, there are quite likely to be incompatible changes in the standard library ABIs between major versions. Something as simple as changing the size of a struct can break the ABI, even though it still maintains the same API and exactly the same soure code, once recompiled, will work just fine. Symbol versioning allows a single shlib to provide older variants of an ABI as well as the latest one, which means you can get both forwards and backwards compatibility. I don't think that the symbol versionning support is comprehensive enough yet, or well tested enough yet that the advice to re-install everything on a major upgrade will be changed any time soon. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --qL9Sr04p1jH4uFEOEaKOf005OvtHtr2KV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQJ8BAEBCgBmBQJU4PunXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATZ70P/25Vz+8FP5CiXFGG58UWZrwH AKVL81SeDgwJc1MqSk6qSv+xAJO+vZfPPrjJ6wnIrI8zgvnzMmJMoxLzAxlv7SbF d9y2Nox+sVqI8YI2UXm4LQjHQdJd5sFiANnPxgcVnxY0nsjW+k22/rwjFpE926n9 DDdYxtkS6Gix19ITpZUEw+3BngS/LKvn+OkI6qiHnEHB+IMZHxnnmD4VvEtnug/D T9z3Oh15a3YwyI/qSzYqHKCq8affIigmFnHdS9bPCzMIwzJy61ne7p07E8TEWVOH eFB5Dxb0vA1iIqEPYSTGnn0HqCKu1aiGy0OiwT0gC0y3wb12BIwN9o+zMg3OpCpa DbSSZIMVpjPvsWQLdaMAowk9PkJnwqJ2QS6+rL/PKh6D6L7YLibx481RujkrvMEk Tq7tc7PL3bQ3bkE5ZzQhMds1c+3aRXSpHOirWeTzkSqDbLqQDy1wpJ/f/8p2caNi ukOB277Fb1buBr3sZGVp86p9BDxskvCGGhd8ihRKFb10w9FtZT05dXe5nyWggO+M BenckMdqm2u3UyL0xoy7Ras2IYUfXi6x9K/beNqcTNdOK8w+birWG6dgF+3cOOXm mivfRdghzqfpfQpLjD0fy/dG7H0pCTcHh8d2cCqiDl1BF/q7IEo+H9m9YEcpBH0z TcqoA5OkLfCO1PNoUM7S =58Ui -----END PGP SIGNATURE----- --qL9Sr04p1jH4uFEOEaKOf005OvtHtr2KV--