From owner-freebsd-pkgbase@freebsd.org Mon Apr 29 12:55:25 2019 Return-Path: Delivered-To: freebsd-pkgbase@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDA8E158C2F0 for ; Mon, 29 Apr 2019 12:55:24 +0000 (UTC) (envelope-from ken@ixsystems.com) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A66776553 for ; Mon, 29 Apr 2019 12:55:24 +0000 (UTC) (envelope-from ken@ixsystems.com) Received: by mail-yw1-xc30.google.com with SMTP id i66so3644046ywe.5 for ; Mon, 29 Apr 2019 05:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:mime-version:message-id:in-reply-to:references :organization:user-agent:content-transfer-encoding; bh=GXyl7dap6IhRxhaABRUI74rtV+3oGDw+iiyBLaSZjr0=; b=HNkhaSiuxB25DBBRJUtgiok0TfRjj1m6D3XN55XwvglULsTwEnbkI3B4yOlNDYd92W U3R01jnWPniAQ5J+JHdBwVxgPDyfVi31O2RGXfOfqr/H+85p32u9+ax80kZ8s7WLScmL yMpFXHiY7iJqKBJAIw3m+WM59wi8Z03RUDberpgqUq80Wlhb5m+NS9GaK4/Wfn+HFJPM CT0RcWk06gV4g1hadf7wvfKTTZibA6fJ+AqMIJHmi2hFh8OqHiGN2V/2+SzFRUgZR8hn hgJIZrjq/FhvIiZvseL7wHfzNMQ0Wk3Oso5vdeGADAUA7k85ayTUu3UPwYZIkPebfLks v1ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:mime-version:message-id :in-reply-to:references:organization:user-agent :content-transfer-encoding; bh=GXyl7dap6IhRxhaABRUI74rtV+3oGDw+iiyBLaSZjr0=; b=BlanS91WDC7x8vq4l83Cea1vTUxbA4xgTo/EbJudF0fLxdfCq4Nfwa402atoyQErnS Cjr2bX07YiXSbiGPuLxPZChPeqDmsihtxj5zRxF4VP9iyQlz1msDwnzN0EsaWv/N+Fcc KS41u/NK5AkOH9i3ABIbxDVuFpS5i+byKvJ2eGWhpMWBz4lPF3PiMVkGd6QiMklVx+B8 XvObriNcPdBiEAuyv//Fnu8/8hEHxzzZUtibdzP6HRUWZ24JGGZZm6+1pFyJIsu1oRCC kXiSA4YAAhTk6DD8KkQPaH132+AIV3H4CxJ1QpNq2dZRWYV3p54xWnrXb/MQwpVU5aFS JugQ== X-Gm-Message-State: APjAAAXMk1eN281cPhWejmd52GBws7r9qtvUpgGDkp//Zkr6YAtFtIGI UyNl5X72TK66HX8AWCK9M0M1bxkTiDrpDZbpjkeUik6uTUkzWJ/skca4Nb4oGyKon1L/LEX202y m6ITaGOw/oFtyVvU5c8yZ0A32mJbsI8c3f4dhalr4m/hB1kQBwxStb6cMbIKHBVU/krT5QVss X-Google-Smtp-Source: APXvYqx61ZLrZ53EO1xaQCzQdTm+PeIALEEHNv9iK3Lvsnh3sSG370i7kkWMovoxdwdoGLBp/Jgyuw== X-Received: by 2002:a81:2f83:: with SMTP id v125mr50872653ywv.259.1556542523156; Mon, 29 Apr 2019 05:55:23 -0700 (PDT) Received: from localhost ([12.189.233.130]) by smtp.gmail.com with ESMTPSA id s127sm16051656yws.66.2019.04.29.05.55.21 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 29 Apr 2019 05:55:22 -0700 (PDT) From: Ken Moore To: Subject: Re: CFT: FreeBSD Package Base Date: Mon, 29 Apr 2019 08:55:21 -0400 MIME-Version: 1.0 Message-ID: In-Reply-To: <20190429120808.GI85201@kib.kiev.ua> References: <002901d4fdfb$e52eb890$af8c29b0$@ixsystems.com> <20190429120808.GI85201@kib.kiev.ua> Organization: iXsystems User-Agent: Trojita/0.7; Qt/5.12.2; xcb; AnyBSD4.4FreeBSD; Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5A66776553 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.973,0] X-BeenThere: freebsd-pkgbase@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Packaging the FreeBSD base system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 12:55:25 -0000 On Monday, April 29, 2019 8:08:08 AM EDT, Konstantin Belousov wrote: > Cc: list trimmed to relevant. Very long essey below, be warned. > > On Sun, Apr 28, 2019 at 03:52:21PM -0400, kris@ixsystems.com wrote: >> FreeBSD Community, >>=20 >> =20 >>=20 >> I'm pleased to announce a CFT for builds of FreeBSD 12-stable=20 >> and 13-current >> using "TrueOS-inspired" packaged base. These are stock FreeBSD=20 >> images which >> will allow users to perform all updating via the 'pkg' command=20 >> directly. ... > > I do not know what are design decisions for trueos pkgbase are, but I > do know something about in-tree split and why some packaging decisions > where made. I cannot attend your WG, but I believe the reasoning used > for the in-tree is important enough to represent it intact from the > source. I have to start with some explanatory long text to put it into > the proper perspective. > > There are two knots of interdependinces which are critical for correctness > of any upgrade where the target system cannot be simply=20 > discarded on failure: > 1. C runtime > 2. Minimal boot path to prompt. > Let me elaborate both, starting from point 1, which is=20 > typically very obscure > despite having the fundamental nature for anything related to upgrades. > > The basic execution environment for any program executed by the FreeBSD > kernel is formed by combination of kernel' syscall interface and some > system userspace code which makes the expected environment over the > bare-bone image state after execve. The environment is typically named > C runtime environment since C language ABI is directly tied into it, > and normal C programs only get whatever is provided by the C runtime > unless additional libraries are linked in. Trully, it is not just C > runtime, any other execution environment on top of the OS is based on > this one, but since almost every 'advanced' language runtime is backed > by C language and its runtime, the name stuck. > > FreeBSD C runtime, arguably, is provided by the following four objects: > =09/libexec/ld-elf.so.1 > =09/lib/libc.so.7 > =09/lib/libthr.so.3 > =09/lib/libm.so.5 > There, we do *guarantee* that the external ABI of the whole pack of > these four objects is backward compatible, i.e. if the binary was > compiled against set if base libraries at earlier date (may be also > on earlier branch), then the binary behaviour would be same when > executed on newer C runtime pack. This is not trivial to achieve, > besides technical measures that helps there, like backward-compatible > syscall interface, symbol versioning, providing fall-back code for > older interface, a lot of overhead in the development is enforced, like > carefull reviews of the changes, the policy and related discipline of > versioning, following published ABI standards, and so on. > > But, internal ABI of the C runtime pack, i.e. interfaces which make rtld > work with libc and libthr, or way by which libthr, when loaded, makes > libc thread-aware, are not stable, and more, they are often changed > in backward-incompatible way. Requiring backward-compatibility there > would stop our ability to evolve the system. Answering some questions in > advance, yes, rtld delves into libc, libthr patches libc on load, libc > has hooks to control some libthr behaviour. > > The only provision that we make is that ld-elf.so.1 is required to work > with older libc/libthr combination, but even then libc and libthr must > be built from the same sources with the same options set. > > Now, returning to pkgbase, if you look at what libs are packed into clibs, > you see: > =09ld-elf.so.1 > =09libc.so.7 (and modules like iconv tables or nss, if any) > =09libthr.so.3 > =09libdl.so.1 > =09libgcc{, _eh, _s}.so.1 > =09libm.so.5 > =09libedit.so.7 > =09libncurses{, w}.so.8 > =09libc++.so.1 > It adds very popular libs like libncurses/libedit, and C++ runtime. The > basic reasoning is that this package is small and chances of something > going wrong while installing it are small as result. Put it other way, > the small clibs package organization makes it highly probable that > system is left in the consistent state (either all new libs, or all old > libs) after the upgrade, whetever the outcome is. > > If the C runtime pack is not split from the whole 700MB+ update blob, libth= r > update has almost certain chance to occur long after or before libc update,= > so failures do tend to leave inconsistent rtld/libc/libthr set. At best, > it gives you strange glitches, at worst you get unusable system that cannot= > be repaired without external media. > > Now, the second item, the minimal boot path. By definition, it consists > of everything that is required to get bare-bone shell prompt in single > user mode, and where user can repair failed upgrade. Arguably, it should > also include the tools to configure the network and fix filesystems. So > it should consists of > =09loader (including forth/lua scripts) > =09kernel > =09C runtime > =09/sbin/init > =09/bin/sh > =09newfs/fsck/tunefs for UFS > =09zfs/zfspool and libs for ZFS > =09ifconfig/route/ping > In this set, zfs and network management tools must be synced=20 > with the kernel, > since ABI of the management syscalls is not guaranteed to be stable even > on stable branches. > > The above brain dump is at least partial enumeration of things that were > discussed between me and Glen when Glen created the current in-tree > packaging code. Konstantin: Please read the pkgbase documentation that Kris posted in the CFT=20 (https://trueos.github.io/pkgbase-docs/). Your issues/questions keeps=20 referencing the packaging used in the current FreeBSD base-package=20 implementation instead of the pkgbase system proposed in this CFT. TLDR: The package format proposed here does not follow the=20 current/experimental base package format, but rather is a new ports-based=20 implementation which tries to mimic the traditional distfile outputs of=20 FreeBSD in package form. Because this new base package system is governed by ports instead of=20 in-tree changes to the freebsd source tree itself, this allows for the same=20= base package implementation to be used on almost any version of FreeBSD=20 that you like: which is how 12-STABLE and 13-CURRENT package repos were=20 both trivially created for this CFT. --=20 ~~ Ken Moore ~~ ken@ixsystems.com