Re: What setup method is planned for pkgbase?

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