Re: BSD Installer as a replacement for sysinstall?

On Tue, May 03, 2005 at 06:32:42PM -0600, Travis Poppe wrote:
> For quite some time I've been looking forward to seeing sysinstall go
> and be replaced with a new system that's user interface agnostic. This
> would allow developers to create a user interface of their choice
> without having to muck around with the internals of the installer. It
> seems that one of the major reasons this hasn't happened yet is simply
> due to lack of development.
> 
> Correct me of I'm wrong, but as far as I know, this is what BSD
> Installer (the DragonFly team's installer) currently does.

I'm very interested in seeing improvements to the installation and
management utilities, but I think many of the current problems are
architectural in the way the base system is packaged, which to me means we
need to widen the discussion to more than just the 'installer' program.

Jordan Hubbard wrote an article about these sorts of issues a long
while back. It took me a while to find it, but here it is:
http://people.freebsd.org/~jkh/package-and-install.txt
Five years on, and it reads as if it were written yesterday.

Also note here:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4914+0+archive/2001/freebsd-announce/20010916.freebsd-announce
There are links to a binary updater project and a sysinstall replacement
project. Both are dead as far as I can tell.

And from about a year ago:
http://lists.freebsd.org/pipermail/freebsd-libh/2004-May/000031.html

I think this shows that:
(1) we're going over old ground;
(2) producing a solution which eliminates the weaknesses of the current
installer is actually much more difficult than people generally think; and
(3) this discussion probably belongs somewhere other than freebsd-current.

The main problems that have affected me with sysinstall, mostly relating to
binary upgrades, are listed below. Most of these would require a lot more
radical overhaul to fix than just replacing sysinstall with something that
has prettier buttons. That's not to say there's no value in just replacing
sysinstall with a prettier UI, but it would leave a lot of things unsolved.
I see little use in having an easy first-time install if upgrading to future
versions is not equally easy. In that case, FreeBSD is likely to become
labelled as "insecure" as it discourages people from keeping up to date.

Now that I have tons of bandwidth on DSL and a fast CPU on my desktop I've
moved to doing source upgrades, but there are plenty of people in the world
who:
(a) don't have the bandwidth or CPU
(b) don't have the experience
(c) conceptually prefer the idea of running the exact binaries that were
released by the FreeBSD project [I fall into that group]
(d) have hundreds of live servers which need to be upgraded, and don't see
why they should have to compile the OS hundreds of times, degrading the
service on those machines while it takes place, nor have to build the
necessary infrastructure such as a local cvsup mirror.

Personally, I think that addressing the needs of these groups of people is
more important than making sysinstall prettier.

Regards,

Brian.

-----------------------

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.

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.

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)

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.