Wed, Mar 10, 2010 at 21:27:29, basil wrote about "Re: [uanog] apache dummy question":
ну давайте поофтопим :)
нормальные дистрибутивы конфиги не затирают
в частности федора: создает файл-конфиг с расширением rpmnew (кажись так, ибо пользую федору сугубо на десктопе) во фре: если софт ставиться из портов, то каждый ментейнер заботиться о том, чтобы конфиги не затирались, а если не получается у ментейнера - то коммитеры всегда помогают, даже русского коммитера находят если надо :)
_Нормального_ подхода по-настоящему я не видел нигде. Потому что единственный нормальный подход, jIMHO - это использование VCS, при котором есть ветка канонической формы конфигов (в CVS такое называется vendor branch) и ветка текущих конфигов, и при накате нового состояния выполняется слияние (merge) правок из текущей ветки и ветки канонической формы. При любом другом подходе, не обладая комплектом из двух разностей (diffs) 1) между прошлым каноническим состоянием (C0) и текущим содержанием (A0) 2) между прошлым и текущим каноническими (C0 и C1) невозможно гарантированно вычислить A1 (то, что должно получиться в результате). Подход RPM даёт A0 и C1, но не даёт C0. В случае отсутствия конфликта слияния должно выполняться A1 = A0 + (C1 - C0) или же A1 = C1 + (A0 - C0) а лучше оба одновременно, это означает, что диффы C1-C0 и A0-C0 взаимно коммутативны, и это идеальный случай. Но если хотя бы один из этих вариантов выполнился без проблем (при текущем уровне интеллекта системы слияния в VCS) - это уже достаточный аргумент ставить такой конфиг как результат слияния. Остаются случаи, когда автоматическое слияние ломается. Например, если у нас в C0 было написано Port 34567 а админ заменил в A0 на Port 45555 приход C1 с записями ListeningPort 34567 OutgoingPort 34567 не может быть автоматически обработан. Понятно, что A1 должен в этом месте получить как минимум следующее: ListeningPort 45555 OutgoingPort 45555 для достижения той же функциональности, что была при апгрейде. Но грамотный админ, видя обе разницы, с этим справится. Среди виденных мной существующих сейчас практических подходов мне максимально осмысленным представляется подход FreeBSD. Он предполагает слияние при наличии A0 и C1 и позволяет удобно управлять этим слиянием в случае заметных расхождений (и автоматическое решение в типичных случаях), предоставляя удобную оболочку для интерактивной обработки (а не поиска .rpmnew по всему файловому дереву). К сожалению, он не предусматривает сохранение C0, поэтому наиболее типичная автоматизация не происходит. -netch-