From owner-freebsd-stable Tue Mar 24 21:51:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12507 for freebsd-stable-outgoing; Tue, 24 Mar 1998 21:51:02 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA12487 for ; Tue, 24 Mar 1998 21:50:51 -0800 (PST) (envelope-from softweyr@xmission.com) Received: from slc418h.modem.xmission.com.2.70.166.in-addr.arpa (xmission.com) [166.70.2.164] by mail.xmission.com with esmtp (Exim 1.82 #1) id 0yHj5M-0006QS-00; Tue, 24 Mar 1998 22:50:48 -0700 Message-ID: <35189C4F.BB17496F@xmission.com> Date: Tue, 24 Mar 1998 22:55:27 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Derek Flowers CC: software@kew.com, stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk Derek Flowers wrote: > > On Mon, 23 Mar 1998, Wes Peters - Softweyr LLC wrote: > > > 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. This is an excellent idea -- I hadn't thought of supping just kernel source. Since that will/does work fine, let's not replace it. > 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. Precisely my worries in this area as well. I didn't want to leave 'out in the cold' those users to wish to track -STABLE, wisely modify their kernel to remove drivers, etc., they don't have, but cannot "make world" for what- ever reason. I like your solution better -- they can CVSup the kernel source and use our update packages to fill in the userland binaries, config files, etc. > > - /kernel.GENERIC > > - system configuration files in /etc, etc. (pun intended) > > Again, no problem. Is there any way to pick up the userconfig changes in the currently booted kernel and apply them to /kernel.GENERIC, so the user won't lose their userconfig changes? That'd be a neat trick, but certainly not necessary. > > 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. That should work fine. I can see the setup now: a simple machine with two identical disks. When SNAPxxxx is created, the 'updater' installs it on 'disk 2', boots that, and diffs the filesystem against SNAPxxxx-1 installed on 'disk 1'. The files that differ are used to roll the update. > > > 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. Yeah, something like that. For those who are space-challenged, symlink can swoop to the rescue at a moments notice. > Real Men (T) don't know the meaning of the word ``GUI''. Really Real Men (tm) don't needs GUIs because they can type 120 wpm. ;^) (And use Bash for those unfortunate little misteaks^H^H^H^Hakes.) > 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. Tk is your friend here. What I had proposed was writing a Tk applet that displayed a simple 'update my system' button; when the user pushed the button it would essentially spawn 'cvsup; cd /usr/src; make world; make install". JMB decided we should call it DAS, because anyone who needed such a tool would necessarily be "Dumb As Sh*t." ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message