From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: 386BSD PARTIAL PATCH KIT NOW AVAILABLE
Organization: Weber State University  (Ogden, UT)
Distribution: usa
Date: Tue, 15 Sep 92 17:50:03 GMT

In article <1992Sep15.142229.1832@rwwa.COM> witr@rwwa.com writes:
>Terry:
>
>It isn't obvious from what has already been posted, so I'll ask:
>
>Is the serialization of patches done using a ``pre-requsites DAG'' as in
>``patch16 requires patch3, patch8, and patch9 to have been already
>applied'' or is it done by requiring patch0--patchN-1 to be applied before
>patchN?  Or some other way?

The serialization is based on conflict resoloution.  That is, if patch00001
modifies /etc/ttys, patch00002 modifies /usr/include/sys/stdio.h, then
patch00003, which modifies /etc/ttys (bringing it to patch level 2) requires
patch00001 be installed.  In this case, patch00002 is optional.  The
following table illustrates the advancement in patch level from the base
distribution (represented by "-"):

Patches		ttys	stdio.h	foofile
----------	-------	-------	-------
patch00001	1	-	-
patch00002	-	1	-
patch00003	2	-	-
patch00004	-	2	1
patch00005	3	-	2
----------	-------	-------	-------

Thus:

	patch00001 requires nothing
	patch00002 requires nothing
	patch00003 requires patch00001
	patch00004 requires patch00002
	patch00005 requires all patches (patch00002 is required by
		patch00004, even if patch00005 diesn't require it directly)

patch00005 will *not* report the requirement of patch00002 if you attempt
to install it before the other patches, since I only report the immediate
prerequisites rather than building a directed graph for the available
patches (something rather hard to do in shell script 8-)).  I have
intentionally arranged the patches (you may notice that several of the
X patches are represented, but not all of them are) so that they tended
to avoid being "lumps" of "patch everything" so as to minimize dependencies.

This is only an example, and in reality the patch requirements aren't so
nearly connected.  This is because the set of files is drastically larger
than the set of patches.  Hopefully, 0.2 and subsequent releases will
insure that this stays true.

In general, you can install all the patches, then deinstall the ones you
don't like.  If there is a follow-on dependency, it won't let you
deinstall, and will tell you what it is.

If you are asking this because you want to produce patches, *please* tell
me; I have patch-production software I can reluctantly give you (reluctantly,
because it put me in the position of librarian to insure that there aren't
patch collisions, and elevates me to the undeserved post of patch number
assignment god).  Any patches that use the "patches" program should be
created with this software.  I also have accompanying documentation and
tutorials, but I feel that if I were to just generally release it, we
would end up in the same boat we wre in, with large number of incompatable
patch kits divirging after patch00019.  This would be a bad thing.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd