Date: Mon, 23 Mar 1998 15:46:50 -0500 (EST) From: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> To: "Daniel O'Callaghan" <danny@panda.hilink.com.au> Cc: stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. Message-ID: <Pine.BSF.3.96.980323153103.13675A-100000@portwwwbus.tc.cc.va.us> In-Reply-To: <Pine.BSF.3.91.980323172519.300J-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Mar 1998, Daniel O'Callaghan wrote: > > I think Derek is doing a great job! Congrats. However, I do also think > that Cy Schubert made a very valid point that we need to identify what it > is that is going to be updated using this package mechanism. > > If the pkg mechanism include feature enhancements to the system, then > people may be reluctant to use it, lest they change somethin on > which their system depends. Alex changed the size of the ipfw structure > and created an incompatibility between ipfw(8) and ip_fw.[ch] last > November/December. The result was that a kernel upgrade meant a > userland upgrade for ipfw(8). This is likely to be a good reason many > will shy away from enhancement packages. > > If the pkg mechanism is only for bug fixes, that's fine, until you need > to produce a package for a bug fix in an enhancement. > > The only way to cater for both scenarios is to flag each package as > either ENHANCEMENT or FIX, and make any FIX packages dependent on the > ENHANCEMENT package. > > Of course, if there is a bug fix in (e.g.) ipfw which is unrelated to, > but after, an enhancement, we need two packages. > > As you can see, this is starting to get yucky, and it is a good reason to > sit down and work out exactly what it is we want to achieve with this > upgrade mechanism. > > Does anyone else have any ideas? > > Danny I originally wanted to do this to cover patches that correct bugs in the release distributions. An example would be the lpr fix for 2.2.5-RELEASE. It seems like a simple idea, instead of having to install the sources, apply the diffs, and recompile, why not just have a patch that contained the already compiled patch and use it to repair the fix. There is no reason why the same idea cannot be applied to the overall OS for updating, patching, installing, etc. Right now, I'm working on converting the distributions over to package format, mainly to use the package database as a means of confirming what version is installed. After getting this done, I can work on updates and the problems that go with them such as uninstall options, version checking, etc. The main problem to face after I get the package format to work is creating an install disk to work with the package format. I am clueless on how to go about doing this. Right now, I am testing the packages by installing a minimal distribution to the test computer and using pkg_add to add all the distribution packages to the system. There is also the ``staging area'' problem that I haven't been able to solve. I hope this answered your question. ---------------------------------------- Derek Flowers djflow@erols.com http://portwwwbus.tc.cc.va.us/~djflow "640K ought to be enough for anybody." -Bill Gates, circa 1981 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980323153103.13675A-100000>