From owner-freebsd-current@freebsd.org Wed Apr 20 10:43:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55410B16917 for ; Wed, 20 Apr 2016 10:43:13 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9D71135F for ; Wed, 20 Apr 2016 10:43:12 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from ox-dell39.ox.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id BF1551156E for ; Wed, 20 Apr 2016 10:43:08 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/BF1551156E; dkim=none; dkim-atps=neutral Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> From: Matthew Seaman Message-ID: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Date: Wed, 20 Apr 2016 11:43:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160420094806.GJ6614@zxy.spb.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ" X-Virus-Scanned: clamav-milter 0.99.1 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 10:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ Content-Type: multipart/mixed; boundary="SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> In-Reply-To: <20160420094806.GJ6614@zxy.spb.ru> --SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/20/16 10:48, Slawa Olhovchenkov wrote: > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? >=20 > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: >=20 > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. >=20 > How do this with many packages? Hmmm.... Good point. At release time, a set of packages will be generated. These will all have the version number of the release eg. 11.0. That's simple and unambiguous. Subsequently adding patches will add a patch level to the version, so 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel will cause the output of uname(1) to show the new patch level, but updates to user land should be reflected in the output of freebsd-version(1). That's exactly the same as now, and assuming you, as an end user, install the default set of FreeBSD packages and apply all the patches as they come out, then there should be no problem. This implies that /every/ patchset will include an update to the package containing freebsd-version. What packaging base does do is allow you to be selective in the patches you apply. So, for instance if patch -p1 was not relevant to you, you might not install it. So you could end up with a system where you hadn't installed patches -p1 -- -p9 but you did install patch -p10. The freebsd-version(1) output would presumably show the system as 11.0-p10 -- but that's certainly not the same as a system with all of those patches -p1 to -p9 applied. Or you could just install the updated freebsd-version(1) package and have your system blatantly lie about its patching status. So, yes, this does change the meaning of the version number string. It's morally equivalent to tracking the releng/11.0 branch in SVN but compiling your system with various WITH_FOO or WITHOUT_BAR flags, and possible local modifications to the code base to back out certain commits. It's still 11.0-SOMETHING but it's not clear exactly what that something should be. Hopefully people that do such things will be sufficiently technically sophisticated to be able to characterize their problems based on the versions of any relevant FreeBSD packages. On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. Cheers, Matthew --SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD-- --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXF101AAoJEABRPxDgqeTnh1wP/RdWDzk1StzV5FY2apDAa7ww SIhGfCHPnwRE4kGo9R2dTskHkhbLUCGvnhhycUf+XMOG6t1neG3h0esso3pF8WuS 8fl46O+u2gyUSPQ3OdkFvkrb5TMBiI4RdxeiOxS09eQRJZUrnq8n+i3o0l9cymVi vJ7fhm95x8viIZo0jesGX7FvRZsWYNBTPW5ta1cZvLTX4y65JV2zjZoWoarfiJnH xqOyPlgr6LStP5KA+au0og0yHcFWduXtVLX/xALEkoMFHYeWQ5YPk0qLAPi1xv4S AAZ0tAn/y6p3Sc0J7Qs7rGBPZ5rccfcnJ6fEuOMWdEznCN8N0Fn3Q6vD6mpIy1vI GlUKr2L7T1dPZib48gL6R1Z4HB/67y1gR5eCEeOuhTsuep5FhMc+xi7EoEHqCmFJ HIOdZn44aOlqeP4AoupccA+LRSeohxMVX0hkjS8zP+yRgInE+RR/57kbUU4hOEB9 7reXqVxSQ4IByfO80VTa5deme1MpJEs5f2IRuQjp8+fpj2OYIeU3CcX4qkrJVz2k cMYy9KRKhA/YYOQaWJ4OaD0Z1ZINElX5cfoyobCHTFnNsu7cTJGNjIThxJ3KQx2F QdcJMjBWZ+07FeyAsHEEvQYmv/j0cYijoc9PiXTdp7wYTFKGJlg5qnrwiNBn73P0 0Itxg/iANPBzbxcgFBBt =9hRt -----END PGP SIGNATURE----- --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ--