From owner-freebsd-current@freebsd.org Wed Apr 20 12:24:02 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 83430B15BF1 for ; Wed, 20 Apr 2016 12:24:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 435291087; Wed, 20 Apr 2016 12:24:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asrAo-000E8P-Jt; Wed, 20 Apr 2016 15:24:02 +0300 Date: Wed, 20 Apr 2016 15:24:02 +0300 From: Slawa Olhovchenkov To: Matthew Seaman Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420122402.GK6614@zxy.spb.ru> 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> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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 12:24:02 -0000 On Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote: > 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? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > > > 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. This is about RELENG, what about STABLE and CURRENT? > 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. New numbering scheme is very hard problem...