Date: Mon, 23 Mar 1998 15:09:27 -0700 (MST) From: Wes Peters - Softweyr LLC <softweyr@xmission.com> To: djflow@portwwwbus.tc.cc.va.us (Derek Flowers) Cc: softweyr@xmission.com, software@kew.com, stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. Message-ID: <199803232209.PAA27779@xmission.xmission.com> In-Reply-To: <Pine.BSF.3.96.980322032911.10136A-100000@portwwwbus.tc.cc.va.us> from "Derek Flowers" at Mar 22, 98 03:39:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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
- Kernel object files
- Files, devices, etc., in the kernel source tree
- GENERIC and LINT kernel configurations
- /kernel.GENERIC
- system configuration files in /etc, etc. (pun intended)
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.
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.
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.
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'. ;^)
--
"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?199803232209.PAA27779>