From nobody Wed May 10 11:40:12 2023 X-Original-To: pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QGY405vp2z49mdf for ; Wed, 10 May 2023 11:40:16 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QGY3z6CTTz3Fqg for ; Wed, 10 May 2023 11:40:15 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de; dmarc=none Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 34ABeCe9001121 for ; Wed, 10 May 2023 13:40:12 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A5DEB8CC for ; Wed, 10 May 2023 13:40:12 +0200 (CEST) Subject: Re: What setup method is planned for pkgbase? To: pkgbase@FreeBSD.org References: <81e4426a-7b8f-f84a-f201-0892f460c2b8@omnilan.de> <4f8e6e12-e13e-2f06-c039-93c773627693@madpilot.net> From: Harry Schmalzbauer Organization: OmniLAN Message-ID: Date: Wed, 10 May 2023 13:40:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@freebsd.org MIME-Version: 1.0 In-Reply-To: <4f8e6e12-e13e-2f06-c039-93c773627693@madpilot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [0.23 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; NEURAL_HAM_SHORT(-0.47)[-0.467]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[pkgbase@FreeBSD.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[omnilan.de]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[pkgbase@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QGY3z6CTTz3Fqg X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N Am 10.05.2023 um 12:09 schrieb Guido Falsi: > On 10/05/23 11:44, Harry Schmalzbauer wrote: ... >> Since the ammount of machines to deploy massively decreased for me, >> and pkgbase seems to be more or less ready ('make packages' left a >> beautiful repo), I want to replace my customized installation methods >> (transfering all it's features for optional usage). > > I don't have definitive answers to the other questions (details below), > but I'd suggest you use poudriere to generate the pkgbase repos. It has > the advantage of only replacing required packages on subsequent builds, > which helps if you happen to update and only a few files are modified > (leverages repeatable builds) Thanks for the hint! For building, I used to use a custom buildtools-package too, which handled cutomer-specific configurations and adaptions (pre-populate configs into the customer-specific distarchives). But it also became useless resp. much too much maintenance effort (hirarchical config-layout and maintaining the tools), since I'm not responsible for many dozends of individual FreeBSD setups anymore. I like the concept of src-env.conf very much (as opposed to the one of poudriere). For building binaries (world/distribution) destined for foreign machines, I'm completely fine with e.g. these few lines to influence/separate standard builds: cat /etc/src-env.conf #DT_PLATFORM=KabyLake DT_MACHINE= _DT_PLATFORMCONFROOT=/usr/local/etc/deploy-tools/platforms .if empty(DT_PLATFORM) DT_PLATFORM=UNSPEC .endif .if make(install*) SRCCONF=${_DT_PLATFORMCONFROOT}/${DT_PLATFORM}/${SRCTOP:T}/src-install.conf .else SRCCONF=${_DT_PLATFORMCONFROOT}/${DT_PLATFORM}/${SRCTOP:T}/src-build.conf .endif # In share/mk/src.sys.obj.mk, OBJROOT:= assignment takes place, hence it's fine # to adjust here in order to strip $SRCTOP path components (OBJROOT must end with /) #OBJROOT=/usr/local/share/deploy-tools/obj/${SRCTOP:S,/usr/local/share/deploy-tools/,,}/ OBJROOT=/usr/local/share/deploy-tools/obj/${DT_PLATFORM:S/UNSPEC/FreeBSD/}-${SRCTOP:T}/ 'make packages' leaves a perfectly valid repo, no need for any extra tools here. >> I'm planning to use whatever FreeBSD uses by default.  Currently, it's >> bsdinstall(8) I guess (which I never used), but I'm not sure if it is >> planned that bsdinstall(8) will be made pkgbase compatible. > > I rarely install new machines from scratch, but for now my strategy has > been to perform a classic install and then just dump base packages over > them, removing unwanted packages later. > > Crude but works, for my needs. Definitely not acceptable if you want to > automate installing more than one machine at a time. So I have little > insight in this regard. Intresting method. Is it planned that 'classic install' will simply utilize pkg(1) for setups from scratch one day? After a brief look into src/usr.sbin/bsdinstall/ I'm planning to start with making /usr/libexec/bsdinstall/jail pkgbase aware. Wondering if anybody already has thought about how to ask user what packages she wants to get installed and which one to skip... Meta-pkgs? (need to learn some pkg(8)'s concepts too in order to find a good solution, which must provide the user with the flexibility to select/deselect _any_ package, but without forcing to go through the complete list, so most important is sane defaults here, maybe grouped...). Most important is to provide a description for all packages - user can know that FreeBSD-acpi-14.snap20230508065013.pkg is not of much use in a jail, bot how can she decide if FreeBSD-libbegemot-14.snap20230508065013.pkg is needed in her jail or FreeBSD-libcasper??? I guess there exist dependency-only packages. If so, these are candidates not to be shown for selection at all. But rest would still be much too much for individual selection, even if we would provide a clear description what FreeBSD-ggate provides (one example of what probably no non-FreeBSD user can know and even many FreeBSD users don't). Thanks, -harry