From owner-freebsd-current@freebsd.org Tue Apr 5 09:14:34 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 53AFAB022BD; Tue, 5 Apr 2016 09:14:34 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 175C01645; Tue, 5 Apr 2016 09:14:30 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from business-89-133-214-251.business.broadband.hu ([89.133.214.251] helo=[10.160.11.151]) by marvin.harmless.hu with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1anMxV-0002VS-Nk; Tue, 05 Apr 2016 09:07:37 +0000 Subject: Re: Packaging the FreeBSD base system with pkg(8) To: Glen Barber , freebsd-pkgbase@FreeBSD.org References: <20160127223323.GG98557@FreeBSD.org> Cc: freebsd-current@FreeBSD.org From: Gergely Czuczy Message-ID: <5703805A.7090204@harmless.hu> Date: Tue, 5 Apr 2016 11:07:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160127223323.GG98557@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 05 Apr 2016 09:14:34 -0000 On 2016-01-27 23:33, Glen Barber wrote: > As many know, work has been in progress for quite some time to provide > the ability to package and upgrade the FreeBSD base system using pkg(8). > The majority of the initial implementation has provided much of the core > functionality to make this possible, however much work still needs to be > done. > > Over the past few weeks, there have been several inquiries on if this > work is still targeted for the 11.0-RELEASE, as well as the status of > the project branch (base/projects/release-pkg). > > The answer to the first question is: Yes. This is still targeted for > 11.0-RELEASE, which was one of the requirements during discussion of the > new support model announced early last year [1]. > > The status of the in progress work is a bit more complex to answer in > a short email, but work on packaging the FreeBSD base system is indeed > ongoing, and has been my primary focus over the past several weeks. > > I am finishing an initial list of outstanding items that need to be > resolved before the project branch can feasibly merged back to head, > which I will send to the new freebsd-pkgbase@ mailing list. People > interested in discussion surrounding this topic are urged to subscribe: > > https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase > > Finally, I want to personally thank Baptiste Daroussin for all of his > tireless efforts to get us to the point we are at now. Without his > ideas and insights, as well as ensuring pkg(8) contained the necessary > functionality, we would not be anywhere close to completing this work > for the 11.0-RELEASE. May I ask how are you going to handle the tricky merging part, like /etc/master.passwd? Usually that file has entries from 3 sources: - From the Base system, which might change between releases - From installed ports - Manually created entries. Also, quite often entries from the base system are changed manually, think of root's/toor's password. Are such cases going to be dealt with properly between upgrades, including self-built-and-packaged base systems? Currently it can be a PITA with mergemaster to handle things like master.passwd properly between upgrades, automation so far wasn't famous on doing it properly. Another thing is, there are a couple of parts of the base system where we add or remove features using knobs, and those take effect at multiple places. Like if I want to have wireless support, there's a bunch of userland utilities being built, and (the important part) some utilities are going to be built differently, like ifconfig. Is handling such features implemented properly by packaging base? We still have to be able to switch between different builds using the new tools. Another thing is, sometimes when upgrading systems, to make things easier, I deploy the new major version of base, leave old libs/stuff in there till I rebuild and upgrade the packages installed, and after that remove the old libs (rm-old-libs target IIRC). The reason for this, for smaller systems there's usually a build jail which produces packages, and it needs to be upgraded to the new release to make the packages for it, so it's a bit of catch-22, and running rm-old-libs late just solved the issue. Is such a functionality still supported during upgrades? That is, upgrading base systems first in a way that old packages are still functional? It's a very big projects, with lots of corner cases and difficult issues to tackle, I really appreciate your effort on this. Best regards, Gergely > > [1] > https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html > > Thanks. > > Glen >