NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5742

Text File | 1992-09-15 | 4.0 KB | 80 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Re: 16550; 386BSD 0.2; Kernel-Book
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
References: <[e-mail]> <[e-mail]>
Date: Tue, 15 Sep 92 17:11:56 GMT
Lines: 68

In article <[e-mail]> [e-mail] (Bernard Steiner) writes:
>BTW while we're at it - is anybody working on a concept of upgrading 0.1 to
>0.2 so that we don't go re-formatting and re-disklabelling and re-newfsing
>and re-installing (once it actually happens) ? - Just a thought.

I would say that this would take a "cannonical" installation mechanism;
otherwise, there's no knowing which version of what has been installed.

This probably would take the form a of "Package installation" program with
requirements files, etc.  I personally vote for something along the lines
of the SCO model.

The problem is in the initial revision levels of the files and knowing
what has been installed.  Assuming that there are installation files and
installation logs maintained, this would probably take the form of a set
of files for each of the "tiny", "bin01", "etc01", and "src01" sets which
we have currently.  This will give us installable "packages" for systems
within the sets... one for uucp, one for a link kit (missing now), one
for uucp, one for networking, etc., etc..

Once we have this, replacement is easy based on deinstallation of the old
software and reinstallation of new software.

A complicating factor is the source distribution, which will probably require
handling as optional parallel installation with the kits which are derived
from it.

I kind of doubt that this is planned for the 0.2 release, since not only is
there a lot of work in installation that would be of little additional
benefit to anyone who was not already resource bound (disk space), but the
time-to-upgrade would probably be more than what it would have been
otherwise.

The problem is that the major beneficiaries, those people who are using
386bsd for developement work (primarily of the OS itself), would probably
not benefit that much from incremental update.  It's an end-user thing,
and it would be a problem orders of magnitude greater in scope than the
simple patch kit mechanism I have put together so far.

Anyone who has ever used the SCO "kitinstall" developer's package is aware
of the work that goes into something like that, escpecially the utilities
like "fdfit" for determining how to pack the most information on the
fewest disks (a "traveling salesman" problem).  That, and determining where
to split the utilities up between packages, is a major issue.  Is "cut"
part of the base system?  Are "nroff" and the man pages?  Or are they part
of the "text processing" package?

There is also the assumption of centralized update to binaries.  This is
good for an end user, but bad for developement, in that all our patches
and work would have to be "clearing-housed" through a central source for
developers and users alike.  This is something I have already done to an
extent with the patchkit system.  I do not like it, but have rationalized
it as an interim fix for 0.1 to try and encourage a larger user base that
is not composed entirely of the kernel-literate, something which I see as
vital to the continued success of 386bsd.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------