Differential D56717
bsdinstall: do pkgbase installations with the "script" command Authored by asomers on Wed, Apr 29, 7:50 PM. Tags None Referenced Files
Details "bsdinstall script" will now do a pkgbase installation unless the MFC: 2 weeks Ran bsdinstall manually. Also, built a DVD and installed a VM from that image.
Diff Detail
Event TimelineComment Actions It's not the same thing. That older revision changed the default interactive installation to pkgbase. What my change is is for the non-interactive installations. That is, the installations that the CD will do if you put an /etc/installerconfig file on the CD. Comment Actions What do you suggest instead? Is there a different phrase to use, or should I make pkgbase mandatory in bsdinstall and remove mention from the man page? Comment Actions My point is, that commit made the default depend on what's on the installation media. Should this change not do the same, rather than make it always pkgbase? Comment Actions Well, it does still depend on the installation media. But it's based on the /etc/installerconfig file. If /etc/installerconfig specifies distsets, but the installation media doesn't include those, then I suppose the installation might be broken. Are you suggesting that a single installerconfig file ought to be usable for either pkgbase or distset-based installation, and which is actually done ought to be based on whether the media includes base packages? I actually tried that first. But it doesn't work, because there's no 1:1 correspondence between distsets and pkgbase components. Comment Actions I recently learned that the official term is freebsd-base(7). However, we (NanoBSD GSoC) are (also?) using the NOPKGBASE nomenclature (double negative is worse). Regardless, we plan to align with the outcome of this review. Comment Actions
Could we not do
Comment Actions I don't think we should, because both of those variables are optional. DISTRIBUTIONS, if unset, defaults to "base.txz kernel.txz". COMPONENTS effectively defaults to "minimal pkg kernel". So we can't require one of those two to be set. I suppose we could do:
Comment Actions that's not the official term for "pkgbase", it's just the name of the manpage. (it's also not a very good name, but no one could come up with a better suggestion at the time.) when referring to pkgbase in documentation we usually say something like "base system packages". for a variable name, you could use NO_BASE_PACKAGES, or if you're only installing the base system, NO_PACKAGES. edit: or use something like METHOD=packages/METHOD=distsets.
Comment Actions Actually @emaste we can't do what I just suggested, because either packages or distsets might need to be fetched over the network. It's valid for neither to be on the installation media. So if you don't like the PKGBASE=no variable, then the best proposal I can come up with is:
Comment Actions I can understand we want to keep it as close as to what it currently is. And now I agree that this should be the way to go. PARTITIONS=DEFAULT PACKAGES="FreeBSD-set-base FreeBSD-kernel-generic puppet" # Or PKG_LIST #METHOD="packages" # This is the default #!/bin/sh sysrc ifconfig_DEFAULT=DHCP sysrc sshd_enable=YES This gives the user the power to choose a FreeBSD-kernel-minimal, for instance, and an à la carte set (or non-set) of components. We then check that a FreeBSD-kernel-* and (FreeBSD-set-base or FreeBSD-set-minimal) are present.
Comment Actions Oh right, of course.
At a high level this approach sounds reasonable to me. IMO we ought to either Comment Actions @emaste I went with option B since there isn't a 1:1 mapping between COMPONENTS and DISTRIBUTIONS. @jlduran the current Lua code doesn't make it possible to install both base and non-base packages using the same variable. It could maybe happen in the future, but not for now. And it's not the way that the interactive installer works. So an installerconfig that installs non-base packages still needs to look something like this: export COMPONENTS="base debug lib32" ... #! /bin/sh ... /usr/sbin/pkg install -y sysutils/py-salt Comment Actions i haven't tested this, but the changes as described seem reasonable to me. for installing extra packages: when we added set support to bsdinstall, we also changed it so that, e.g. when you don't install sshd, bsdinstall doesn't prompt to start sshd. one suggestion was that, instead, if the user selects sshd, bsdinstall should install it in addition to the selected sets. i think, if someone wanted to work on making it possible to install arbitrary packages, it would be worth doing it in a way that works for both the interactive and script installer, which might address both issues. Comment Actions Yes, thank you for the feedback and thank you for working on this.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||