Date: Tue, 24 Mar 1998 00:08:40 -0500 (EST) From: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> To: Wes Peters - Softweyr LLC <softweyr@xmission.com> Cc: software@kew.com, stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. Message-ID: <Pine.BSF.3.96.980323233422.14462A-100000@portwwwbus.tc.cc.va.us> In-Reply-To: <199803232209.PAA27779@xmission.xmission.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Mar 1998, Wes Peters - Softweyr LLC wrote: > Derek Flowers asked: > > I've done some quick and dirty work on binary package updates and would > > like some comments on what I've got going, where to go in the future, etc. > > Thanks for diving right in. I've been reading this thread, and have > tried to summarize the current state of questions, comments and > concerns thusly: > > So far, it seems we have the following points to ponder in our > thumbnail design. I've interspersed my comments on each point, you > may feel free to agree, disagree, or ignore them; this is a > *discussion*. ;^) > > o Are patches designed to just fix problems, to add features, or > what? > > Both. Past experience in -stable branches has shown that there are > periods of activity when one of our developers fixes a bug or updates > a subsystem, followed by periods of inactivity. I propose that > patches be created to update systems to "snapshots" of the -stable > tree that roughly reflect these periods of relative inactivity. For > instance, when a security bug is noticed, there is generally quite a > bit of discussion, and one to several commits on the -stable tree > related to fixing the bug. When consensus has been reached that the > bug is closed and the system stable, the activity dies down. At that > time it would be appropriate to create an UPDATE that fixes this > problem. > > The same cycle tends to apply to an update of a system utility, > i.e. the recent fix for disk slice names. > > Updating to known (and perhaps CVS-labelled) sync points on the > FreeBSD stable tree also makes it somewhat easier to report problems, > since what you end up with is a system equivalent to a known point on > the -stable tree. > > This means each UPDATE would require *every* previous UPDATE as a > pre-requisite. This may be a major flaw in this approach, but it does > simplify the design considerably. To make it simplistic as possible, we could just diff 2.2-SNAPxxxx and 2.2-SNAPxxxx-1. The result is the daily changes for the -stable branch. We could also diff 2.2.SNAPxxxx and 2.2.X-RELEASE getting all the changes since the RELEASE was tagged. > o Are we patching (or replacing) executables, the kernel, source > code, or what? > > All of the above, with limitations. Ideally, we'll be able to detect > what you have installed on your system and update those parts. > > We'll need to update, at a minimum: > > - Binary executables > - Man page sources No problem. > - Kernel object files > - Files, devices, etc., in the kernel source tree > - GENERIC and LINT kernel configurations Aren't the kernel object files located in the kernel sources? At this point, someone should just CVSup the kernel sources and make a new kernel. Since kernels are custom built, updating them in place is next to impossible. I'm not for changing anything in the kernel with patches right now. Maybe we can work on creating kernel updates that contain not only the sources but the object files necessay to build them. Even with this method, user intervention is necessary to configure and compile the kernel. > - /kernel.GENERIC > - system configuration files in /etc, etc. (pun intended) Again, no problem. > Obviously, if anything inside the kernel is modified, the user should > be encouraged to review their kernel configuration against the new > GENERIC and LINT and rebuild their kernel. > o Who is going to make these patches? > > As with all other FreeBSD jobs, whoever volunteers. Ideally, this > would be SEVERAL someones who use FreeBSD-stable in their daily work > and really need this feature. If they're willing to commit the > updates to their systems, the updates are probably in good hands. If we stick to doing snapshots, this can be an automated process done at the same time the SNAPxxxxxx snapshots are rolled out. > o Where do we save the files we are replacing, so we can back out the > patch? > > In the same place pkg_add already puts this kind of information? I > don't know, this is a good question. I'd like to see all of the > replacements for a particular update stored in a gzipped tarball to > save space and inodes, personally. Maybe something like /var/updates? Wherever they go, there needs to be plenty of room. > o How do we authenticate the packages so we can be sure we're not > installing the new FreeBSD kernel virus from Chaos? > > The JAR signing mechanism mentioned by Eivind sounds like a great > methodology, if package users are not required to install the JDK. If > packages creators have to install the JDK in order to build the > signature, that should be acceptable. Not too familiar with the JAR signing mechanism, but we need to be careful of ITAR regulations. I believe GNU is doing some work on a PGP work-alike that is available outside the U.S., it may be useful here. > o Should we use binary diffs? (What are binary diffs?) > > Binary diffs mean that we could send out just the bytes in any changed > file, rather than the whole file. For many updates, where you are > changing only a few small features in a large binary, the diff could > be quite a bit smaller. > > This is a cool idea, and would save users a lot of download time in > the future. On the other hand, binary diff utilities are non-trivial > to create. I'd say if we can find binary diff and patch utilities to > add to the system, use them, but it's not worth delaying the > implementation to wait for this feature. We can always add it in the > future, as an update. ;^) > > o What do we do if the user has modified some source on their system? > (Either kernel or userland source.) > > Politely explain to them we designed this tool for binary-only systems > that don't have source installed, and invite them to use CVSup and > 'make world.' > > Seriously, handling kernel (or userland) patches to the source tree is > a little beyond the scope of this utility. For users with large > numbers of systems, ideally we provide them the facility to make their > own updates, where they can CVSup on their 'configuration' machine and > make updates to push out to their remote binary-only machines. These > local updates would, of course, include their local changes. > > o What about a GUI for this? > > As I said before, write a little Tk program with an 'update' button > that goes to the stable ftp server, figures out what the highest > update available is, and passes it to pkg_add. Any prerequisites not > installed locally will be automagically brought over and installed by > pkg_add. > > Maybe we can write a simple 'current update level' server running on > port 244, which reports the highest update level posted as an unsigned > 16-bit number for each connection, and run it on the server. > > JMB recommends calling this tool 'DAS', for the class of user it is > intended for. Being acronymically enabled, I'll vote for 'Do Update > Maintenance Bull****', or 'dumb' for short. Gee, with a little more > thought, I could probably even come up with an acronym for > 'dummy-up'. ;^) Real Men (T) don't know the meaning of the word ``GUI''. Unfortunately, my skills at XWindows interface programming are naught. At it's simplest, it could fetch a list of all current updates and allow the user to choose to install those not already on the system. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://www.xmission.com/~softweyr softweyr@xmission.com I finally got my testbed machine up and have applied the distribution packages. Any comments on what I should look for while testing? ---------------------------------------- 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.980323233422.14462A-100000>