On Thu, Jun 13, 2019 at 17:07:36 -0000, Christos Zoulas wrote: > In article <[email protected]>, > Valery Ushakov <[email protected]> wrote: > >On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > > > >> On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > >> > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > >> > > >> > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > >> > > > [...] > >> > > > I've been using etcupdate for ages so I only ever really used > >> > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > >> > > > kinks and may be we should concentrate on fixing those instead? > >> > > > >> > > I *never* used etcupdate, so for me it's better to have a working > >postinstall > >> > > (I have a PR about it: install/52349, which may have been fixed by the > >> > > recent change) > >> > > >> > The rc.d part is probably addressed by this very change that Christos > >> > made (that i was replying to). > >> > > >> > The other part is exactly what I'm talking about. postinstall does > >> > NOT update your system to the new etc.tgz set, it cherry picks stuff > >> > from the new etc.tgz. > >> > >> It should create files and directory that are expected to be there > >> but are not. > > > >That "should" seems to be the crux of the matter. It seems that > >different people think that postinstall should do different things. > > >Most new files added to etc that were not previously there are not > >needed to boot your system with its old etc (shinynewd may be hip and > >progressive, but if that system ran without it, it will happily > >continue to run without it for the time being). My conception of > >postinstall has always been that it takes care specifically about > >those rare cases where a new file in etc *is* required to keep the > >system operational and you, for whatever reasons, can't/don't want to > >do a full etc update. I may be misremembering, it's been about 15 > >years, please correct me if I do. > > No, this is correct (most shiny new files are not needed). There are > problems though: > 1. Files that get updated sometimes need the new files (npf for example > recently), and break otherwise.
Was that file that get updated also in etc, as I understood from your private comments - in which case the new file won't be there since you still have mostly old etc, right? If something in the base set changes that requires a coordinated update to the configuration in etc then yes, that's the prime thing for postinstall to fix, as I understand. Consider e.g. ssh check that moves existing(!) /etc/ssh* files to /etc/ssh/* > 2. There is significant amount of work to keep things synchronized over. > There are multiple places people need to edit when adding/removing stuff > and this is error prone. Right. > 3. Keep upgrading and you end up missing more and more files in > /etc. What's the mechanism *in base* to help you keep them in > sync. etcupdate(8)? I've been using it all this time, since Martti committed it to base. I used it to upgrade very old machines (my mr.coffee hasn't been booted in a decade since 2007 and I upgraded it in 2017 and it was all very smooth). As I said, it has its kinks. Special handling for passwd/group would be very nice and -a (automatic) should really install new files without asking. Other then that I really love it. Adding a bit more user-friendliness to it might be in order simpley because most people that don't track current only use it may be once in a couple of years, so some handholding in this rather delicate task of merging new etc would definitely help to reassure them. > 4. Unpacking sets installs programs, postinstall deletes programs. This is > driven from the sets. OTOH their respective rc files don't get installed > or removed from postinstall; this seems inconsistent to me. For example, > dhclient got removed as a program, the rc file is still there. > The automount stuff got installed as programs the rc files did not. postinstall fix obsolete will delete programs, yes, but it should not be run blindly. Say, oldd is removed from base, as long as you don't run fix obsolete, you should be fine. Except, as I mentioned, fix rc seems to also delete obsolete rc files, in which case fix rc might screw your system by deleting oldd rc script (while the oldd itself and oldd.conf are still in place). fix obsolete and fix catpages are really quite orthogonal to the rest of postinstall. As I said, I use etcupdate, and obsolete and catpages are the only postinstall fixes that I need to use. So for fix rc to delete stuff seems a bit reckless. Again, as I said, after etcupdate fix obsolete will take care of obsolete etc stuff b/c you will get new /var/db/obsolete/etc When the automount staff got installed, again, that doesn't affect the current configuration of the system as embodied in the state of its etc. You can't use the new stuff untill you do proper full etc update. > I think that the desire here is for postinstall is to be a very safe process > that keeps the system up-to-date with minimal (or zero risk). The question is > how to achieve that? We have risk added because of the manual process of > keeping lists of things that postinstall does, and at the same time we have > risk added by inadvertently adding and running things that were not there > before. But this is not postinstall's fault. We should design things so > that they need to be explicitly enabled by the user. And there is gray > areas, like npf_boot which changes the functionality of the system. > > I would like postinstall to improve in these three areas (in priority order): > 1. Make postinstall as safe as we can, by designing the installed files > properly and blacklisting the dangerous ones. > 2. Automate as much of it as possible so that there are fewer mistakes > or omissions, and less work to be done. > 3. Keep /etc as much in sync with a newly installed system, without > breaking (1). I see two basic scenarios here. 1) install new sets except etc, run only postinstall (without postinstall fix oboslete!!!) to do minimal fixup of the etc to get the new system booting with its old configuration 2) install new sets, use etcupdate to merge new etc. run postinstall fix obsolete when ready. postinstall currently is kinda between 1) and 2). If you try to move it forward to 2) you will be more or less reinventing etcupdate that we already have. -uwe
