advice on compiling a new kernel & upgrading to the latest sources

[Giorgos Keramidas]

On 2007-01-14 15:35, Bill Moran <wmoran at collaborativefusion.com> wrote:
> Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> [copious snippage]
> > > 2. Cd /usr/src/sys/amd64/conf which contains the file MYKERNEL
> >
> > No it doesn't.  CVSup will delete the files it doesn't know about, so
> > you should *SAVE a copy* of your favorite kernel config file outside of
> > the source tree and *copy* it into `/usr/src/sys/amd64/conf' after CVSup
> > finishes updates the sources.
>
> Really?  What have I been doing wrong?  I've been keeping custom kernel
> configs for years and cvsup has never deleted any of them.

That's what the ``*default delete use-rel-suffix'' option does, AFAIK.

The default supfile examples in `/usr/share/examples/cvsup' have this
option enabled, and cvsup(1) says about it:

  delete  The presence of this keyword gives cvsup permission to
          delete files.  If it is missing, no files will be deleted.

	  The presence of the delete keyword puts cvsup into
	  so-called exact mode.  In exact mode, CVSup does its
	  best to make the client's files correspond to those on
	  the server.  This includes deleting individual deltas
	  and symbolic tags from RCS files, as well as deleting
	  entire files.  In exact mode, CVSup verifies every
	  edited file with a checksum, to ensure that the edits
	  have produced a file identical to the master copy on
	  the server.  If the checksum test fails for a file,
	  then CVSup falls back upon transferring the entire
	  file.

	  In general, CVSup deletes only files which are known to
	  the server.  Extra files present in the client's tree
	  are left alone, even in exact mode.  More precisely,
	  CVSup is willing to delete two classes of files:
          o   Files that were previously created or updated by CVSup
              itself.
          o   Checked-out versions of files which are marked as dead on
              the server.

If the option doesn't work this way, then I stand corrected.

>>> 4.Copy everything under /etc to /root/etc
>>
>> Why?  This isn't mentioned in `/usr/src/UPDATING' and it doesn't really
>> help much if you manage to trash your /lib and /usr/lib trees.  A better
>> suggestion is to ``make sure you have good level 0 dumps'', as suggested
>> by ``/usr/src/UPDATING''.
>
> While not mentioned in /usr/src/UPDATING, this is good practice in my
> opinion.  mergemaster can be a tedious task, and making a local backup
> of /etc has allowed me to undo some careless keystrokes a number of times.
> I don't disagree with the dump advice, but an additional copy of /etc
> around doesn't hurt anything and occasionally makes fixing a mistake
> much faster an easier.

Heh, true :)