Eu estou atualizando um sistema FreeBSD 8.3-RELEASE para o FreeBSD 9.0-RELEASE usando freebsd-update . Esta é minha primeira vez realizando uma grande atualização de versão no FreeBSD.
Em um ponto do processo, o freebsd-update executa um diff nos arquivos que são diferentes do esperado para o 9.0-RELEASE. Ele compara a versão atual no sistema com as novas alterações adicionadas do 9.0-RELEASE. Eu modifiquei algumas dúzias de arquivos em / etc, e sou apresentado com este diff uma vez por arquivo.
Assim, sou apresentado a dezenas e dezenas de diffs que abrem em uma janela vi e se parecem com isso:
The following file could not be merged automatically: /etc/ntp.conf
Press Enter to edit this file in vi and resolve the conflicts
manually...
### vi window opens
<<<<<<< current version
driftfile /etc/ntp/drift
=======
#
# $FreeBSD: release/9.0.0/etc/ntp.conf 195652 2009-07-13 05:51:33Z dwmalone $
#
# Default NTP servers for the FreeBSD operating system.
#
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
#
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
#
>>>>>>> 9.0-RELEASE
restrict default notrust nomodify ignore
E reclama de números menores de versão:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.25.28.1 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.25.32.1 2010/12/21 17:10:29 kensmith Exp $
#
# This file is read by manpath(1) to configure the mandatory manpath,
# optional manpath and to map each path element to a manpath element.
# The format is:
#
Does this look reasonable (y/n)? y
E, na verdade, reclama da versão do RCS em dezenas de arquivos:
--- current version
+++ new version
@@ -1,4 +1,4 @@
-# $FreeBSD: src/etc/amd.map,v 1.10.8.1 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: release/9.0.0/etc/amd.map 164015 2006-11-06 01:42:11Z obrien $
#
/defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
* opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev
Does this look reasonable (y/n)?
E até reclama porque removi o número da versão do FreeBSD do meu arquivo /etc/passwd local (personalizado):
<<<<<<< current version
=======
# $FreeBSD: release/8.4.0/etc/master.passwd 243948 2012-12-06 11:54:25Z rwatson $
#
>>>>>>> 8.4-RELEASE
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
E assim por diante.
Isso requer que eu edite manualmente cada arquivo e remova as sequências como <<<<<<< current version >>>>>>> 9.0-RELEASE e ======= e mescle manualmente esses arquivos. Como descobri depois, se eu não remover essas cadeias, elas acabam no arquivo depois. Existem dezenas de arquivos que diferem entre 8.3 e 9.0, e eu tenho uma dúzia de modificações locais.
Parece que freebsd-update está usando uma função diff, sdiff ou mergemaster
O processamento desses arquivos é tedioso. Existe uma maneira que eu posso apenas dizer "Aceitar nova versão" ou "manter a versão antiga" ou "Sua mesclagem está correta"? Tem que haver uma maneira mais fácil de lidar com esses arquivos. Eu devo estar perdendo alguma coisa.
Este não é um grande problema para uma máquina, mas eventualmente eu farei isso dezenas de vezes e quero encontrar uma maneira mais fácil.
E eu não estou sozinho. Pelo menos um outro admin por aí apontou este problema. O autor de Zytrax.com: Guia de Sobrevivência para Atualização do FreeBSD: freebsd-update upgrading versões menores ou maiores também fala sobre esta situação:
Notes:
- When updating to a new release lots of stuff changes (much less so with a minor release). When scripts and configurations files are
modified freebsd-update diffs them, loads them into vi and presents
them for reconciliation. Since most of the changes are simple version
number comment field changes this can be a serious pain (in our case
well over 50 files were changed, over 40 were comment only changes).
However, be warned - diligence is necessary (no :wq to every file
without looking). Further, unless the file is visibly short all the
diff marks (:/>>>/) need to be viewed and reconciled. Failure to do
this will cause the resulting file to contain the diff indicators and
many essential system files will simply croak when loaded (including
the password file in our case) resulting in endless hours of fun
looking for the files that were modified (guess how we found this
out). While there is really no alternative to genuine file changes,
having to undergo the edit reconciliation for comment only changes
results in a serious shortcoming in the process. Better, perhaps, to
move the replaced files into a special location and let the user
manually reconcile those of interest. Just how often do you change
/etc/periodic/weekly/310.locate?
Atualização:
Parece que esses diffs são gerenciados por merge (1) , não mergemaster. Da mesclagem (1) manpage:
A conflict occurs if both file1 and file3 have changes in a common seg-
ment of lines. If a conflict is found, merge normally outputs a warn-
ing and brackets the conflict with <<<<<<< and >>>>>>> lines. A typi-
cal conflict will look like this:
<<<<<<< file A
lines in file A
=======
lines in file B
>>>>>>> file B