Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1705 ; Tue, 23 Feb 93 14:54:30 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!amdahl!JUTS!cd.amdahl.com!gab10
From: gab10@cd.amdahl.com (Gary A Browning)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] A few patchkit comments
Keywords: n
Message-ID: <d4vz02yz361N01@JUTS.ccc.amdahl.com>
Date: 19 Feb 93 18:52:24 GMT
References: <1993Feb16.182649.28351@zip.eecs.umich.edu> <1993Feb16.212839.10641@coe.montana.edu>
Sender: netnews@ccc.amdahl.com
Organization: Amdahl Corporation
Lines: 45
In article <1993Feb16.212839.10641@coe.montana.edu>,
osynw@gemini.oscs.montana.edu (Nathan Williams) writes:
> In article <1993Feb16.182649.28351@zip.eecs.umich.edu>
> dmuntz@quip.eecs.umich.edu (Dan Muntz) writes:
[ deleted ]
> In my opinion, the reason for the patchkit was to set up a base of
> reference for other people. It is not mandatory, but it makes it easier
> for fols to make changes and patches based against this version, and it
^^^^
Huh?
> makes it easier for those people who are working on different parts of
> the system to get patches in areas that they aren't working on.
[ deleted]
> >It would be nice if packages such as pcfs, julian's scsi drivers,
> >cgd's com.c, etc. were made part of the kit (say, patch90001,...).
> >Even if the latest, greatest versions were not included, it would make it
> >much easier for people dependent on certain packages to upgrade (thanks cgd,
> >for getting the 0.2.1 com.c out so quickly).
>
> The only problem with that is that the current form of the patchkit software
> enforces an order in the patches. Therefore, to apply Julian's patches,
> it would be a simple patch (there are some other issues, but if you really
> want to know about those, send me mail). The next driver that is added
> would REQUIRE that Julian's scsi patches be installed, and the next driver
> would require Julian's and the previous driver stuff was installed, and
> the next driver would require.....
Can you describe the problems in a little more detail.
I would really like to see the drivers distributed as additional patch files
built on top of the current base level patchkit. Lets see if we can't work
out some of the problems in doing this.
I assume that one of the problems is the interdependencies of all drivers on a
few configuration files. This would cause the driver patch files to have to be
applied in order. I have some ideas on how to solve this one.
What are the other problems?
--
Gary Browning | Exhilaration is that feeling you get just after a
gab10@cd.amdahl.com | great idea hits you, and just before you realize
| what is wrong with it.