tim foster explains how this particular thing works with IPS http://timsfoster.wordpress.com/2011/11/09/ips-self-assembly-part-1-overlays/ Also, check the IPS developer guide
On Thu, Jan 17, 2013 at 11:01 AM, Jim Klimov <jimkli...@cos.ru> wrote: > On 2013-01-17 12:59, Stefan Müller-Wilken wrote: > >> Dear all, >> >> while updating from OI 151a_5 to 151a_7 worked smoothly for me, " pfexec >> pkg image-update -v" overwrote (at least) my dovecot configuration files >> without backing up the existing ones (e.g. as rpm would with .rpmsave >> files). Yet another time I was happy to use OpenIndiana with its boot >> environments and snapshots. :-) >> >> Is there a pkg command line argument to influence that behavior and have >> pkg save those files? Or is it entirely up to the respective package to >> trigger that in its spec file? What's the best practice in that case? Mount >> the old boot environment and then manually copy config files to the new >> boot environment? But how would I know what to look at? >> >> Would be great if someone could point me at some best practices. TIA! >> > > Well, not that my answer is immediately relevant, but back in the > days of Solaris, SVR4 packages (where config files were marked as > "editable" or "volatile" FS object type, and/or had some "class" > assigned to them to trigger update/merge scripts), the LiveUpgrade > system copied the old files to something like hosts.~10 and then > replaced or intellectually merged them with those in the update. > In the end of the upgrade process it warned about the 30 or so > files (as well as packages whose updates generated warnings) that > should be revised by the admin to validate that nothing was broken, > before activating the new BE. For us it was usually the sendmail > config that might need tweaks returned... > > As for IPS - I don't really know yet, how it plays around such > rough edges. However, many programs converge toward a "config.dir" > approach so that the packaged master config can automatically > include your custom snippets and have no update conflicts... > > Overall, it may be wrong to just take your old configs and copy > over the updates - the newer programs might include new features > and keywords which you may want to retain from the new default > config or even customize. Notorious for that are the PAM files > that may include hooks for newer programs or features that are > integrated by default in the newer release of an OS. > > I usually make a practice of copying the original configs with > a backup suffix, then making modifications, and then when an > upgrade comes with a new baseline packaged config file - some > sort of 3-way diff (manual or automated) can be applied to > promote my modifications over the new default config. > > For you, perhaps, "zfs diff A B | grep '\.conf'" might be helpful > to find any changed files which match the pattern. When you do, > "diff" them couple by couple to see if the changes are trivial > (i.e. comments updated) or some more work is needed from you. > > HTH, > //Jim > > > > ______________________________**_________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@**openindiana.org<OpenIndiana-discuss@openindiana.org> > http://openindiana.org/**mailman/listinfo/openindiana-**discuss<http://openindiana.org/mailman/listinfo/openindiana-discuss> > _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
