Date: Tue, 24 Mar 1998 22:55:27 -0700 From: Wes Peters <softweyr@xmission.com> To: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> Cc: software@kew.com, stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. Message-ID: <35189C4F.BB17496F@xmission.com> References: <Pine.BSF.3.96.980323233422.14462A-100000@portwwwbus.tc.cc.va.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35189C4F.BB17496F>