Subject: Re: another 1.1 to 1.1B (i386) upgrade report...
To: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 03/27/1996 14:49:57
[ On Wed, March 27, 1996 at 12:31:18 (-0500), Chris G. Demetriou wrote: ]
> Subject: Re: another 1.1 to 1.1B (i386) upgrade report...
> In (2), you get the new (binary) release going, make the sources work
> with your changes, then recompile and reinstall. It's really Not That
No, it's not that hard. It's just damn annoying to have to repeat
obviously automatable tasks every year or so when I have to do this.
All I'm saying is that, strictly speaking, there should be no
discernable difference between doing a source re-install and a source
upgrade. Following the procedure in the "right" order will effectively
achieve the same effect in both cases.
Note also that your ideas regarding building a proper cross-compilation
system will, as a side-effect I'm sure, result in a procedure that will
work equally well for a source upgrade. So you see, we are really
talking about the same thing, just with slightly different ends. The
requirements are essentially the same, up to a point.
As I see it the only difference between a source upgrade in the hoped
for cross-compilation environment and a binary-only upgrade is that the
latter must work in absence of the source build environment.
> Quite frankly, i've never even thought of doing "complete source"
> upgrades from release to release as something that people do.
That's probably because you live on the cutting edge of -current, and
have read (and write) access to the CVS repository. With many
production machines out in the field, and an unfortunately growing
number with their own locally hacked source trees, these are issues I
think about more and more.
> I've yet to see a vendor that supported it with their source
> distributions. Hell, many of those don't even build cleanly to begin
I've installed an AT&T UNIX source distribution which also happened to
be a minor upgrade (3.1 to 3.2), so yes, it has been done successfully
(it did require a 'make cleandir && make install' equivalent to ensure
full consistency). If memory serves me right, SysVr3.2 source was
fairly close to being able to support full cross-compilation too.
> There's also the "bug reporting hell" problem: if a problem shows up
> in the new system, whose fault is it? there's no longer any common
> baseline with which to compare... (no, i don't really consider "foo +
> lots of local changes" upgraded to "foo+1 + lots of local changes" to
> be particularly representative of either "foo" or "foo+1".)
I don't think this is in any way related to what I'm talking about,
though I agree that it's a potential hornets nest. All the more reason
to do what others are advocating and provide tools with the source
distribution that help users automate the management of local changes
and source upgrades. I hope to have such tools soon, and will offer
them for distribution with NetBSD.
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>