386BSD PARTIAL PATCH KIT NOW AVAILABLE
A Wizard of Earth C
directory /pub/incoming/terry on agate.berkeley.edu. This is not a
complete set, as there are still 10-20 patches not yet in patchkit format.
The following is a list of the patches in the current patch kit.
Remember that the patchkit expects to start with a "virgin" kernel... no
strange hacks allowed.
If you install a new machine, the patches will "just install". If you are
the type that hacks around, it probably won't, but you'll you'll be able
figure out what files each patch modifies from the file named "PATCH" in
the subdirectory for each patch under "ready".
The "README" file is in the tar file, but it is also packed seperately so
you can tell how to install it without having to install it first 8-).
-----------------------------------------------------------------------------
PATCHES IN THE INITIAL PATCH KIT (TOTAL: 19 PATCHES)
-----------------------------------------------------------------------------
patch00001
PATCH: KERNEL REBUILD
AUTHOR: Terry Lambert (te...@icarus.weber.edu)
DESCRIPTION:
This patch fixes the missing vers.o problem which prevents the
kernel from being rebuilt.
patch00002
PATCH: BIG MEMORY HANG
AUTHOR: William Jolitz
DESCRIPTION:
Because of the number of kernel map entries being to small
and an inappropriate calculation for the number of buffer pages, it was
possible for the kernel to hang if you had more than 8 Meg of memory
installed in your system.
patch00003
PATCH: INCORRECT CMOS RAM SIZE CAUSES CRASH
AUTHOR: Terry Lambert (te...@icarus.weber.edu)
DESCRIPTION:
This patch fixes the problem encountered on HP Vectra, AT&T
6386E/33 WGS, AT&T StarServer E, and AT&T 6386/25 WGS systems where
the CMOS RAM size is not what was expected. It also has fixes to
allow running small kernels in 640K, and warns the user of conditions
which may cause the kernel to fail to boot correctly.
patch00004
PATCH: FIRST SECTOR IN MULTISECTOR READ IN BAD144 TABLE
AUTHOR: Frank Maclachlan (f...@crash.cts.com)
DESCRIPTION:
The bad144 table search code at finds the sector in the bad144
table and replaces the block number, cylinder, head, and sector addresses
with values corresponding to the replacement sector. The sector count
register is loaded with the number of sectors in the entire transfer.
This is wrong; it *MUST* be set to *one* sector. A read would return
the wrong data in sectors after the first; a write would *overwrite*
other replacement sectors or even the bad144 table on the last track.
patch00005
PATCH: WHATIS COREDUMP
AUTHOR: Andrew Moore (a...@netcom.com)
DESCRIPTION:
The whatis program had two unitinitialized pointers which would
cause it to core dump sporadically depending on the initial stack contents.
patch00006
PATCH: CRASH FOR PARENT (.) REFERENCE AFTER CHROOT
AUTHOR: Christoph Robitschko (ch...@fstgs01.tu-graz.ac.at)
DESCRIPTION:
When chroot() was used to change the apparent root directory
for a process, a reference to "./", the parent directory of the new
"root" directory, the system "panic"ed.
patch00007
PATCH: GREENMAN BUGFIX KIT
AUTHOR: David Greenman (dav...@agora.uucp)
DESCRIPTION:
1. Buffers were being immediately aged after read, greatly reducing
file system performance.
2. The file system buffer cache hash calculation resulted in hash
collision occuring 100% of the time.
3. File system buffers were allocated twice. They were also deallocated
twice, so there was not a memory leak, but freebufspace was incorrect
and too much memory was being used.
patch00008
PATCH: MAN PATHBUF OVER 1K
AUTHOR: James W. Dolter
DESCRIPTION:
In the function config.c:cadd() the pointer bp isn't recalculated
when the pathbuf needs to be realloced. If realloc moves the storage
'bp' is left hanging. The bug manifests itself when you modify man.conf
such that the pathbuf expands beyond 1k.
patch00009
PATCH: MBUF ALLOCATION FLAGS
AUTHOR: Wolfgang Solfrank (w...@tools.de)
DESCRIPTION:
While the flags in sys/mbuf.h define M_DONTWAIT and M_WAIT in terms
of M_NOWAIT and M_WAITOK, these flags are only used for the kernel malloc.
But the actual code in kern/uipc_mbuf.h uses kmem_malloc, which has
only a parameter canwait. This parameter has just the opposite meaning
from the flag values above. This may result in occasional hangs of the
system (if mbuf allocation with M_DONTWAIT is called which may result in
a wait) or panics or other nasty things (if called with M_WAIT which may
return a NULL pointer that is not expected and as such not tested by the
calling code).
patch00010
PATCH: SCROLLING BACKWORDS ON CONSOLE CAUSES CRASH
AUTHOR: Frank Maclachlan (f...@crash.cts.com)
DESCRIPTION:
I was horrified whilst scrolling backwards in a file with the less
pager at my console when my 386BSD system suddenly rebooted. Subsequent
tests revealed that the system would crash whenever I scrolled rapidly
backwards through this file using less.
Most files won't cause the system to crash. To demonstrate the failure,
do the the following (if you don't mind watching your system crash):
hd /usr/mdec/bootwd >junk # create a file
less junk # invoke less
G # go to the end of the file
^B^B^B... # rapid repeated control B's to
# scroll backwards
patch00011
PATCH: COPY ON WRITE FOR TEXT PAGES
AUTHOR: Paul Kranenburg (p...@cs.few.eur.nl)
DESCRIPTION:
The 386 does not generate a page protection fault while it is
executing in supervisor mode :-(, so copy on write handling never takes
place when the kernel stuffs data into a process's text- or any other
non-anonymous segment. So these cases must be explicitly checked for.
NOTE: This is a security hole where it is possible for any
normal user with access to the debugger and read access
to any suid root program to become root! You should
apply this patch immediately!
patch00012
PATCH: RING BUFFER LENGTH INCORRECTLY REPORTED
AUTHOR: Stephen McKay (rob...@psych.psy.uq.oz.au [forwarder])
DESCRIPTION:
The RB_LEN() macro in /usr/include/sys/tty.h is sometimes out by 1.
In particular, in the case of a buffer containing a single character at the
very end, RB_LEN() would return 0. This caused ttread() to block until a
2nd character was read before delivering them both. The user would find
RAW mode programs such as vi would occasionally (1 in 1024 keypresses) get
"stuck" requiring a second keypress to bring it to life.
WARNING: On the whole, this seems reasonable... HOWEVER, I feel the
problem may be due to the ?: expression grouping. In
particular, perhaps all that's missing is some parenthesis
around "RBSZ - 1 - ((rp)->rb_hd - (rp)->rb_tl)".
patch00013
PATCH: CSH SEGMENTATION VIOLATION
AUTHOR: Ed Hudson (e...@netcom.com
DESCRIPTION:
I have a prompt setting alias in my .cshrc for "cd", that looks like:
alias cd 'cd \,* > /dev/null; set noglob; set xdirs = `dirs`; se
The bug manifests itself when I type:
cd
cd bin01
...csh says "Segmentation fault", and on a repeated attempt, dies.
It seems to occur whenever the target directory is 5 characters in name.
I think that it is blowing up when the statement "set xdirs = `dirs`" is
executed. If I modify /usr/src/bin/csh/alloc.c so that the number of
bytes requested is automatically increased by 4 (on entry to malloc),
then the problem goes away.
WARNING: This is a workaround. The real problem is with the ALIGN
macro getting a 0 for its offset, then the allocated buffer
adds 4 regardless, causing overflow of the buffer on copy.
patch00014
PATCH: CAN'T kill -1 OR kill -15 DAEMONS STARTED IN /etc/rc
AUTHOR: Paul Kranenburg (p...@cs.few.eur.nl)
DESCRIPTION:
The init program doesn't set up the proper signal disposition for
the process (sh) it creates to run /etc/rc. While all signal handlers are
reset to SIG_DFL, the signal mask is left unchanged causing SIGHUP and
SIGTERM to be masked in all daemons started from /etc/rc.
patch00015
PATCH: MAKE HUNG ON SINGLE "-" ARGUMENT
AUTHOR: John Woods (j...@eddie.mit.edu)
DESCRIPTION:
[ This is a patch rolled in from work done on 4.3Reno/NET2 ]
There is a bug in the new make from 4.3Reno and also present in the Net2
release (as found on uunet). A command line argument consisting of a lone
dash (-) causes an infinite loop ("make - make" was an excellent test case).
patch00016
PATCH: NFS SERVER CREATE TRUNCATES FILE
AUTHOR: Arne Henrik Juul (ar...@Lise.Unit.NO)
DESCRIPTION:
The file was always truncated if it existed. The reason why it only
happens when used from certain NFS clients, is that some clients does
not do a NFS create request at all if the file already exists.
patch00017
PATCH: DMA SPECIAL HANDLING/DMA CHANNEL 4-7 TRANSFER COUNT
AUTHOR: Frank Maclachlan (f...@crash.cts.com)
DESCRIPTION:
At line 389 in isa_dmarangecheck(), the automatic variable priorpage
is used without being initially set to 0. This causes the function
to flag special handling for virtually all DMA transfer requests.
Also, no check is made for DMA requests crossing DMA page boundaries
(64k for DMA chans 0..3, 128k for DMA chans 4..7). This problem is
masked by priorpage not being initialized - almost all DMA is done
to/from safe 'bounce' buffers which don't cross DMA page boundaries
and the data are block moved from/to the user's buffer.
In line 359, nbytes is doubled by shifting it left 1 bit; it
should instead be divided by 2 by shifting right 1 bit position.
This occurs when any of the word mode DMA channels (4..7) is used.
patch00018
PATCH: CORRECT MINOR NUMBER FOR COM PORT (SELECT FAILS)
AUTHOR: Christoph Robitschko (ch...@fstgds01.tu-graz.ac.at)
DESCRIPTION:
I had the problem with select() not working on com ports. I got no
response from a post regarding this one, so I started to look into it
myself. I found out that the com driver calculates unit = minor(dev) -1;
This has the following implications:
/dev/com1 corresponds to COM0, /dev/com2 to COM1 (very confusing
in kernel messages)
It is incompatible with the config file entries com1 at..., com2 at...
Unpredictible results will occur if someone puts a com0 at.. in
his config file.
It is incompatible with the DOS usage of COM1, COM2 (But who cares 8-)
ttselect() calculates unit = minor(dev), and uses this as an index in
com_tty. Because this index is different from that used
in the com driver, select() on /dev/com1 looks at
/dev/com2 and select() on /dev/com2 looks at an undefined
entry in com_tty and returns always true.
WARNING: RE-mknod /dev/com1, /dev/com2, and modify your kernel config!
patch00019
PATCH: CLEAN UP SLIP INTERFACE TO KEEP FROM HANGING
AUTHOR: Poul-Henning Kamp (p...@data.fls.dk)
DESCRIPTION:
Here is a patch to clean up the interface between the tty-drivers, in
particular the com driver, and the sl# interfaces, this is not a work-around
but a genuine bug-fix.
Symptoms: after a number of "com#: silo overflow" SLIP ceases to work.
Overview of the problem: the slip interface will disregard any notice
from the tty-driver on problems (parity errors, framing errors or overruns),
which basicly means the one might as well throw the packet away right away.
Also overrun in the packetizing will go relatively unnotized.
-----------------------------------------------------------------------------
Terry Lambert
terry_...@gateway.novell.com
te...@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
-------------------------------------------------------------------------------
David Le Blanc
>I have uploaded the first 19 patches and the patchkit software to the
>directory /pub/incoming/terry on agate.berkeley.edu. This is not a
>complete set, as there are still 10-20 patches not yet in patchkit format.
>The following is a list of the patches in the current patch kit.
>Remember that the patchkit expects to start with a "virgin" kernel... no
>strange hacks allowed.
Please note that this is rather rude, and very restrictive.
Is your patch kit going to help me with the bus mouse driver I have to patch
in? Or make things hard?
Will it work with, or cause problems for those installing the patches for
using X386 ?
Will the X386 patches be incorporated?
Granted I have not seen the patchkit software, I would be happy if you
allowed a modular approach, so that I could add a patch to the
'patchkit' directory, edit some central config file, and run the software.
I may then select the new patch, and have it applied.
Could all patches be kept in a compressed form?
--
David Le Blanc :
Email: da...@mlb.geomechanics.csiro.au : `Sort of a cross between a Jaguar
CSIRO Division of Geomechanics, : and a freight train.' the Alien
P.O. Box 54 Mt Waverley 3149 : in Alien^3.
A Wizard of Earth C
>te...@cs.weber.edu (A Wizard of Earth C) writes:
>
>>I have uploaded the first 19 patches and the patchkit software to the
>>directory /pub/incoming/terry on agate.berkeley.edu. This is not a
>>complete set, as there are still 10-20 patches not yet in patchkit format.
>
>>The following is a list of the patches in the current patch kit.
>>Remember that the patchkit expects to start with a "virgin" kernel... no
>>strange hacks allowed.
>
>Please note that this is rather rude, and very restrictive.
I assume that you mean the reference to a '"virgin" kernel. If you can tell
me how to write a patch program that doesn't require context differences,
I'll be happy to incorporate (and patent 8-)) the technology.
Until then, the patches are incremental in nature. This means for all the
existing patches, I have to start with a "baseline"... ie: a "virgin" kernel,
or some agreed upon baseline. It also means that, in order to produce the
patches in the first place, I have to *manually* go through them to insure
that conflicts between patches are resolved (since there was no incremental
management of the patches in the first place).
If you produce a patch to wd.c and I produce a patch to wd.c, and joe blow
produces a patch to wd.c, there has to be an *order* to the patches so that
there aren't any conflicts. There has to be *enforcement* of this order,
since I can't tell what patches you already have installed, and for the
context to be correct, the order *must* be enforced. There's no other
way I can see to get the majority of patches out to the majority of
people. I have been keeping multiple source trees for baselining from day
1 to facilitate this.
>Is your patch kit going to help me with the bus mouse driver I have to patch
>in? Or make things hard?
If you are talking about the Logitech one posted here, then it will simply
install as a patch, as will the AT&T EN100/PC-10 NAU ethernet board drivers.
It's true that I haven't taken into account automatic rebuild (at least not
yet) of the patched files. This is partly because I am rolling in the 4.3
Reno patches posted to the net, and I can't be guaranteed a full source tree
anywhere but the kernel (how do I remake "init" after it is patched, for
example?). I will probably be including a machanism for kernel rebuild
and a tag to indicate that it is necessary, but have done nothing on it so
far. I suppose I will have to include the running of MAKEDEV as well.
I have also not placed it in an easily accessable area; casual browsers
won't find it, and it won't be echoed to other sites mirroring agate.
This is intentional; the thing is admittedly "alpha". In particular, the
code identifying falure to install the patch and patches 14 and 16 have
problems. Patches 14 and 16 can be incrementally deinstalled until this
is fixed (it's fixed now, but upload will wait until tonight). When it
goes "beta", meaning that I know all patches so far are represented and
that they install correctly, I will ask Chris to make the thing public,
and it will get mirrored everywhere.
>Will it work with, or cause problems for those installing the patches for
>using X386 ?
Obviously, if the context diffs for the X are not taken against baseline code,
there will be problems. Certainly there will *not* be problems if the diffs
are against a "fully patched" kernel, or if the affected files are patch
level 0 (new files) or part of the original distribution, and are not touched
by the patch kit.
>Will the X386 patches be incorporated?
The ones on agate in the incoming/X386 directory *have been*; they just
haven't been posted yet (I felt it would be easier to debug 20 patches
at the same time rather than 40 of them -- so sue me). If there are more
recent versions, they will require incorporation against baseline, which
is defines as the patches you have applied and the patch level of the
file affected.
>Granted I have not seen the patchkit software, I would be happy if you
>allowed a modular approach, so that I could add a patch to the
>'patchkit' directory, edit some central config file, and run the software.
>
>I may then select the new patch, and have it applied.
It is modular; however, because I haven't been able to work out how to
(automatically, preferrably) manage baselining, I haven't distributed the
patch-building software (mkpatch) or it's documentation, or the tutorial.
I am currently trying to work with Nate (the bug list keeper) on a way to
manage this, and when we have something, I am sure we will post. Until
then, I will probably keep incorporating patches as they are posted. To
directly answer, the question, however, NO, YOU CAN NOT CURRENTLY MAKE
NEW PATCHES BECAUSE YOU DO NOT HAVE THE PATCH PRODUCTION SOFTWARE, AND
ANYONE THINKING OF MAKING PATCHES IS STRONGLY DISCOURAGED FROM PUTTING
THEM IN PATCHKIT FORMAT THEMSELVES BECAUSE OF THE CONFLICT MANAGEMENT
ISSUES WHICH STILL NEED TO BE ADDRESSED.
>Could all patches be kept in a compressed form?
Initially, all the patches *are* in compressed form. The failure of a
compression of compressed data is why the file containing both the patch
kits and the patch software is simply a tar archive (as previously posted).
I do *not* store installed patches or ready-to-install patches in compressed
form; however, the patch generation software does pack them that way for
distribution.
I could not worry too much about disk space, since the way things are
currently arranged, previous patch levels *must* be left around for subsequent
patches to know what has been installed. Later, this will be replaced with
patch removal via "patch -R". I haven't done that yet.
Bottom line: I make some assumptions which cost a small amount of disk space,
which may be too expensive for people who only have a "very small" amount of
disk. These people are unlikely to benefit from the installation of patches
anyway, since they are unlikely to be able to rebuild their kernel. I make
some assumptions about baselining that means you have to have a "virgin"
kernel with no patches to the files to be patched. This is the assumption
that practically all patch posters have held to so far. I make it so an
idiot can patch kernels (not that I expect many idiots to be able to con
anyone into installing the patch software for them, much less knowing how
to usae ftp). I make it so that you can apply multiple patches to the same
file. I make non-prerequisite patches optional (admittedly a value judgement
on my part). I provide a common mechanism for patch distribution so that
patches and new files are not in a bad format because someon forgot the "-c"
option to diff or put the file name parameters in the wrong order.
I am *not* setting myself up as "patch god". Since I expect that 0.2 will
eventually be released, that would be a stupid move on my part, not to mention
that I really already have my hands full at the moment with other things. I
realize that this will probably be the short term effect of "official" patch
numbers, and incremental installation, and am working dilligently to resolve
this. Until then, if you don't like it, don't use it.
Timo Rinne
diffs) available, maybe in tar format. Then we, who have hacked kernel
to fit our needs could just cd to /usr/src and 'tar xvf'. Then just
recompile patched parts of the system (kernel and a few system binaries).
Much easier than sexy automatic patch installation systems, IMHO.
--
I Timo Rinne I Cirion oy I Working computer hardware is a lot I
I Timo....@hut.fi I PL 250 I like an erect penis: It stays up I
I t...@cirion.fi I 00120 HELSINKI I as long as you don't fuck with it. I
Hi! I am a .signature virus. Copy me into your .signature to join in!
A Wizard of Earth C
>Would it be impossible to put all patched source files (not just
>diffs) available, maybe in tar format. Then we, who have hacked kernel
>to fit our needs could just cd to /usr/src and 'tar xvf'. Then just
>recompile patched parts of the system (kernel and a few system binaries).
>Much easier than sexy automatic patch installation systems, IMHO.
I didn't know who would be unhappy about having their patches blown
away with new files. This still has the following drawbacks:
1. Requires centralized baselining.
2. Large propagation delay between baselines.
3. All patches are mandatory.
4. No standard mechanism for determining patch level (in this case,
which baseline a particular machine is currently at).
5. Absolute file locations may not follow symbolic or real links
(ie: I must replace both /src/sys/tty.h and /usr/include/sys/tty.h
if they are linked to each other).
Except for drawback #1, which I hope to work around, the patchkit software
currently gets around these problems.
The canonical alternative, of course, is to install fully patched sources,
which pretty much equates to installing 0.2 when it comes out.
My intent was to distribute the patches that I'm getting the majority of
mail on and to insure that the patch installation order is enforced. This
will reduce my email significantly, and will get nearly everyone else up
to the functionality of the "hackers" systems. This should also reduce
the "newbie" traffic on this group, which is basically why the hard core
BSD'ers are calling for a seperate group for the 386bsd types.
Since several of the patches are of questionable value (ie: some people
have reported worse performance with the patches installed), it seemed
best to find some way of making them optional, rather than forcing you
to trade one intermittent system crash caused by a bug for another
caused by a patch.
Since each of the patches in the patch kit is either a new file or a
context diff, you are, of course, free to apply them yourselves. The
diffs have the full path name in them and are guaranteed to work with
the -c option and are not reversed (unlike many of them when originally
posted). You can look at the "PATCH" file to find the name for any new
files created by each patch.
When I have put together all the patches I have (40, +/- 5), then I will
make a tar archive of the files for those people with blind faith in my
judgement. 8-). Since I only have the first 19 patches done, and the
patchkit is "alpha" (HINT: DON'T INSTALL PATCHES 14 OR 16 YET!), I have
a ways to go. Note that a "tarfile" for a "patchall" wouldn't necessarily
give you a choice of what printer driver you want to run, for instance.
This patchkit that I have put out in no way reflects changes that may or
may not be in the 0.2 code, nor does it necessarily agree with the "correct"
(according to the Jolitz's) view of what it purports to fix. It does
reduce the number of "how do I install this patch and that patch at the
same time" questions that have been deluging me (apparently, I have high
visibility and have made the mistake of trying to answer my mail 8-)). It
will also fix most of the problems most people have been having.
In any case, it's well worth the price (free).
Gary D. Duzan
caused a couple problems with nested comments in init_main.c (the patch
date, I assume). It was a simple fix, but it is a bit annoying in an
official (or semi-official) distribution.
Gary D. Duzan
Network Administrator
Delaware State Hospital
--
du...@cis.udel.edu
_o_ ------------------ _o_
[|o o|] Virtual Reality? No thanks, I've already got one. [|o o|]
|_O_| Disclaimer: I have no idea what I am talking about. |_O_|
A Wizard of Earth C
> Applying these patches to my newly unpacked src01 distribution
>caused a couple problems with nested comments in init_main.c (the patch
>date, I assume). It was a simple fix, but it is a bit annoying in an
>official (or semi-official) distribution.
Definitely "semi" or even "non".
There were reported problems with patch00010, patch00014, and patch00016, as
well as the patch program itself. They have been fixed, and the patchkit is
now at "Alpha 2" level. Thanks to those who reported the problems.
See previous posting for more details.
Aubrey Soper
>te...@cs.weber.edu (A Wizard of Earth C) writes:
>>I have uploaded the first 19 patches and the patchkit software to the
>>directory /pub/incoming/terry on agate.berkeley.edu. This is not a
>>complete set, as there are still 10-20 patches not yet in patchkit format.
>>The following is a list of the patches in the current patch kit.
>>Remember that the patchkit expects to start with a "virgin" kernel... no
>>strange hacks allowed.
>Please note that this is rather rude, and very restrictive.
I'm sorry to be obliged to contradict you, but if you don't
want the benefits of this generous person's labors because
they don't fully satisty your preferences, leave them for
those of us who are grateful for his assistance.
Robert Withrow
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?
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: wi...@rwwa.COM
R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
A Wizard of Earth C
>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.
Ed Hudson
seconding what aso...@azania.twuug.com has said,
thanks very much Mr. Lambert for your efforts in putting
this patch kit together.
-elh
T. William Wells
: 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-)).
Once, I wrote a shell script to determine the set of all
intersections of a set of sets. It's amazing what you can do with
sort, join, comm, tsort, and a few other nifty standard tools.
Supposing you have a collection of patches and a set of
dependencies, as in: X -> Y means that X must be applied before Y.
Represent these as pairs on lines, as in:
patch0001 patch0002
means patch0001 is require for and must be applied before
patch0001. (If A -> B and B -> C, only those two have to be
represented; A -> C doesn't, though representing it is harmless.)
Suppose that a collection of wanted patches are specified. The
following script, give or take a few bugs, determines the complete
set of required patches:
cp $1 /tmp/in # input file
order=$2 # file of dependencies
in=/tmp/in
out=/tmp/out
sort +1b $order -o $order
sort -u $in -o $in
while :; do
join -j1 2 -o1.1 $order $in | sort -u - $in >$out
if cmp $in $out; then
mv $out $in
else
break
fi
done
tsort $order |
egrep -n . |
sort -t: +1 |
join -d: -j1 2 - $out |
sort -n |
sed 's/^[0-9]*://'
How this does it and what the bugs are (hint: I didn't look at
the manual when I wrote those options to join!) is left as an
exercise for the reader. :-)
---
Bill { uunet | decwrl | telesci }!twwells!bill
bi...@twwells.com