Re: BSD Installer as a replacement for sysinstall?

<snip stuff above that I largely agree with: in short, sysinstall
should probably be upgraded/replaced>

> Fundamental issues with the current installation/upgrade process:
> 
> 1. You have a choice of distribution sets to install, but your choice is not
> recorded. Hence when you upgrade, you have to try to remember which
> distribution sets to upgrade. To be safe, whenever you do a binary upgrade
> to have to select "All" distribution sets.

Excellent point and actually the remembering of distribution sets in a
simple fashion would be pretty easy to just work into an upgrade, I
should think.
 
> 2. No record is made of which files were installed; when you upgrade, it
> just untars the new distribution(s) on top of the old. Any files which were
> in the original system but which should not be there on the new system, are
> left lying around. This problem especially affects source code; at the
> moment the only safe approach is to rm -rf /usr/src and reinstall it all
> from scratch (which loses your custom kernel configs unless you copy them
> first)
>
> 3. There is no 'mergemaster' type functionality in a binary upgrade. You
> either get stuck with stale configs, or you manually compare the new configs
> to the old. Inexperienced admins are likely to be left with old and broken
> configs.

This is a problem, as stated, for inexperienced admins.  Whether or
not we should actually play to inexperienced admins is a bit of a
question, but sometimes this is also a problem for
not-so-inexperienced admins, if just an inconvenience.  When config
files are non-back-compatible, things can be pretty ugly.  At the very
least a notification system or similar about new configs.  Perhaps
something similar to what gentoo's emerge does with config files?

> 4. Even with a source upgrade, 'mergemaster' is not clever enough to upgrade
> files which you have not touched automatically. This is especially true of
> the /etc/rc.d/* scripts. You'll see it when upgrading from 5.3 to 5-STABLE;
> you are presented with diffs for dozens of scripts, stuff in /etc/mtree and
> so on. The issue is that for each one, the user has to remember that she did
> not make any changes to that script herself, and hit 'i' to confirm the
> installation.
>
> I think the upgrade should be clever enough to say that if file X was not
> touched by the sysadmin, then it can be safely and automatically replaced by
> the new version of file X. To achieve this would mean keeping a database of
> checksums/hashes of files under /etc. The existing logic, which says do
> nothing if the RCS IDs are the same, should be kept as well of course.
> 
> (Personally I don't consider /etc/rc.d/* scripts to be "configuration" data;
> I see them more like /etc/defaults/* files, which are part of the system and
> you're not supposed to touch. But a system which automatically replaces them
> only if you haven't touched them yourself would be fine for everyone. "rpm"
> has had this functionality for years)

I fear that mergemaster is an issue which would need to be tackled
simultaneously.  Perhaps this is part of what makes the problem larger
than it first appears.  It would be nice to have a system which
gracefully and flexibly could upgrade configuration files and rc
scripts.  There is a problem with upgrading any "untouched" config
file in that often I like the defaults as they were and more the
config before I think about changing it.  If the defaults were to
change, I, for one, would dislike it if just because I didn't change
the old defaults, I was moved to the new defaults.  I would hesitate
to do much without the user actually explicitly causing it.
 
> 5. There should be a straightforward way to say 'upgrade all installed
> packages to the latest ones which are on the CD (or FTP)'. I know this is
> probably possible using portinstall with an appropriate set of options, but
> it's a basic sysadmin function which should be achievable through the
> interface.

This would be nice I think something like portmanager or portupgrade
or similar would be a nice thing to get in base.  (Not trying to bloat
base...and not portupgrade if it would add ruby to base.)

Mostly wanted to say that I appreciate this being brought up again
(though it has been brought up many times) because there is no
apparent opposition to replacing or upgrading sysinstall and it would
benefit a LOT of users.

-- 
If I write a signature, my emails will appear more personalised.