Jen kdyby si s tím někdo hrál (jako já) a měl už někde systémy s pkgbase. Tzn. i základní systém je v balíčcích a nepoužívá se pak klasický nástroj freebsd-update.
V tuhle chvíli je to v 15.x řadě jako test a některé kroky nejsou úplně super dokumentované, ale funguje to.
Schválně jsem čekal na minor verzi, abych si ozkoušel jak se to bude chovat při reálných upgradech.
v konfiguraci repozitáře base v /etc/pkg/FreeBSD.conf je ve výchozí konfiguraci url s proměnnou VERSION_MINOR.
"pkg+https://pkg.FreeBSD.org/${ABI}/base_release_${VERSION_MINOR}"
Ta se ale nespecifikuje přímo, protože si ji nástroj pkg vyseká ze systémové proměnné OSVERSION.
Tzn. pro upgrade na 15.1 na amd64 platformě pak stačí použít:
env OSVERSION=1501000 ABI=FreeBSD:15:amd64 pkg update -r FreeBSD-base env OSVERSION=1501000 ABI=FreeBSD:15:amd64 pkg upgrade -r FreeBSD-base
Zjistí si, že se změnil root repozitáře, znovu udělá index balíčků, nechá si potvrdit operaci upgrade. Následně reboot a je to.
Samozřejmě může dávat smysl udělat si před tím záložní boot environment přes bectl (tohle zatím není automaticky provázané jako u freebsd-update).
Taky pak po minor upgrade chce většinou doaktualizovat bootloader. Na UEFI systémech tedy:
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
(samozřejmě se dají oba soubory předtím porovnat, jestli je to opravdu potřeba)
To si řeší každý balíček zvlášť. Resp. používají se standardní nástroje v pkg. Což je za mě jeden z benefitů tohohle přístupu.
V manifestu každého balíčku (nejen systémového z base repozitáře) jde nastavit sekce config, kde jsou uvedeny všechny konfigurační soubory z balíčku. K těm se pak chová jinak, nepřepisuje je, ale porovná existující a novou verzi, případně použije 3-way merge a kdyžtak dělá zálohy (.pkgsave, .pkgnew).
Prakticky, pokud už to máte nainstalované tímhle způobem, tak se můžete podívat např. na manifest balíčku v kterém je i část souborů do /etc
pkg info -R FreeBSD-runtime
tam máte sekci config, což obsahuje zmíněnou definici souborů.
config: [
"/etc/ddb.conf",
"/etc/defaults/devfs.rules",
"/etc/devfs.conf",
"/etc/disktab",
"/etc/fbtab",
"/etc/gettytab",
"/etc/group",
"/etc/hosts",
"/etc/hosts.equiv",
"/etc/login.access",
"/etc/login.conf",
...
A pak třeba i sekci script, kde jsou zas uvedeny příkazy, co se spouští po instalaci. V tomhle případě to vygeneruje/občerství databáze s loginy atp.
scripts: {
post-install: "pwd_mkdb -i -p -d ${PKG_ROOTDIR}/etc ${PKG_ROOTDIR}/etc/master.passwd\n services_mkdb -l -q -o ${PKG_ROOTDIR}/var/db/services.db ${PKG_ROOTDIR}/"
}
Takže nemusíte dělat ohledně mergování víceméně nic dalšího, resp. pokud chcete být pečlivý, můžete si v /etc/ a /usr/local/etc vyhledat všechny soubory s příponami .pkgsave nebo .pkgnew, porovnat je s aktuálními soubory, a pak si to ručně doupravit.
Ďakujem za info, musím sa s tým niekedy pohrať. Idea správy base systému pomocou pkg balíčkov sa mi páči, ale bral som to ako niečo zatiaľ silne experimentálne a ešte som to v praxi netestoval.
Predpokladám, že tá funkcionalita mergovania configov pomocou pkg bude pomerne nová, lebo pri bežných "aplikačných" balíčkoch som ju zatiaľ ešte nezaznamenal. Zvyknutý som na tradičný prístup, kedy balíčky aktualizujú iba "sample" config files a samotné "aktívne" configy je treba upravovať ručne.
To je trochu paradox, právě že v pkg samotném je tahle funkcionalita už velmi dlouho.
https://github.com/freebsd/pkg/commit/e6cd4064e4f4a62cae8d1cddbaeeda043e1fcadb
A průběžně to vylepšují, třeba pkg 2.0 (pár let zpět) má dokonce v manifestu možnost použít externí nástroj pro merge.
Ale ten největší problém je v tom, že to nemá ekvivalentní funkci v normálních portech. Proto o tom taky nenajdete jedinou zmínku v Porter's Handbook.
V portech se používají jen klasicky .sample soubory, které jsou úplně mimo a veškeré případné mergování musíte řešit ručně.
Není tam ani žádný přechodový mechanismus nebo makro, kdy byste třeba případně mohl "otagovat" konfigurační soubory a vytvořit tu config sekci v manifestu jen v případě, pokud z portu děláte balíček (make package). Protože by se to chovalo jinak podle typu instalace.
Zatímco ty systémové base balíčky vznikají jinak. Když uděláte make buildworld, proleze to přes METALOG až do pkg-create, kde to rovnou nacpe ty manifesty s config sekcemi.
Takže to je důvod, proč se to nepoužívá v "normálních" balíčcích. Ale je evidentní, že s tím pro systém počítali už dlouho, po celou dobu toho kdy chystali pkg base. To samo o sobě bylo taky předmětem mnoha interních debat (výhody/nevýhody.. a názory od "nic takového nepotřebujeme, nejsme Linux" až po "jsme sto let za opicema, nedokážu selektivně aktualizovat jen části systému z binárních balíčků a je to pomalé") :)
Jinak za mě to chodí docela hezky, zkoušel jsem to už v 14, teď s 15 to mám na pár virtuálech.
Krom pár věcí, co si člověk musí uvědomit (třeba to, že tam není ten hook na bectl jako u freebsd-update), jsem nenarazil na zásadnější problémy.
Na případnou migraci (jednosměrnou), kdyby jste si s tím chtěl hrát, tak je pkgbasify.
https://github.com/FreeBSDFoundation/pkgbasify
Jinak ještě jestli si chcete vylistovat všechny soubory, co pkg spravuje jako configy, tak můžete přímo udělat query na databázi pkg.
sudo sqlite3 -readonly /var/db/pkg/local.sqlite "select path from config_files order by 1"