From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <43D2BF01.6030002@solin.spb.ru> Date: Sun, 22 Jan 2006 02:08:49 +0300 From: Aleksey Avdeev User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] QU: M2.4 -> =?koi8-r?B?8zMuMCDQ0s/CzMXN2SDTIHN1?= =?koi8-r?B?YnZlcnNpb246IEJhZCBkYXRhYmFzZSB2ZXJzaW9u?= References: <43D29881.7090307@solin.spb.ru> <20060121205628.GB8741@procyon.home> In-Reply-To: <20060121205628.GB8741@procyon.home> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at dom.solin.spb.ru X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2006 23:09:06 -0000 Archived-At: List-Archive: List-Post: Sergey Vlasov пишет: > On Sat, Jan 21, 2006 at 11:24:33PM +0300, Aleksey Avdeev wrote: > >> Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы >>с subversion (репозитарии недоступны). > > > В любом случае при использовании формата bdb нужно сначала сделать > _старой_ версией svnadmin dump, потом после обновления восстановить > репозитории в новом формате с помощью svnadmin load. С форматом fsfs > подобных граблей нет. В данном случаи, я ССЗБ (на авось, понадеялся). В прочем, в данном случаи мне это и не помогло бы: ошибка всплывает, в том числе и _до_ обращения к базам... > > >>Оказалось, что даже svnadmin работает криво: >> >>$ svnadmin help >>svnadmin: Bad database version: got 4.2.52, should be at least 4.3.28 >> >>(В error_log -- dav ругается на тоже самое.) >> >>Установлено: >> >>$ rpm -qa|fgrep subversion >>subversion-python-1.2.3-alt2 >>subversion-1.2.3-alt2 >>subversion-server-common-1.2.3-alt2 >>subversion-server-dav-1.2.3-alt2 >>subversion-doc-1.2.3-alt2 >>libsubversion-1.2.3-alt2 >>subversion-tools-1.2.3-alt2 >> >>$ rpm -qa|fgrep db4 >>libdb4.3_cxx-4.3.28-alt1 >>libdb4.3-devel-4.3.28-alt1 >>libdb4.3_java-4.3.28-alt1 >>libdb4.3-4.3.28-alt1 >>libdb4.2-4.2.52-alt4.1 >>^^^^^^^^^^^^^^^^^^^^^^ >>db4.3-utils-4.3.28-alt1 > > > А libapr и libaprutil? $ rpm -qa|fgrep libapr libapr-0.9.7-alt0.M24.1 libaprutil-0.9.7-alt0.M24.1 > > >> Смущает выделенное. При попытки снести, получаю: >> >>]$ sudo -H apt-get remove libdb4.2 >>Чтение списков пакетов... Завершено >>Построение дерева зависимостей... Завершено >>Следующие пакеты будут УДАЛЕНЫ: >> apache2 apache2-manual apache2-mod_ssl apache2-mod_webauth >>apache2-mod_webauthldap >> apache2-mod_webauthldap-tests apache2-suexec libaprutil libdb4.2 >>libsubversion subversion subversion-python >> subversion-server-common subversion-server-dav subversion-tools webauth >> >> Как разрулить ситуацию? (Желательно без пересборки. :-)) > > > Непосредственная зависимость на libdb-*.so есть только в пакете > libaprutil - остальные компоненты subversion, похоже, получают libdb > косвенным образом. Возможно, в системе каким-то образом завалялясь > старая версия libaprutil, собранная ещё с libdb4.2 - в этом случае > следует обновить именно её. OK. но облом: $ sudo -H apt-get install libapr libaprutil Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Последняя версия libapr уже установлена. Последняя версия libaprutil уже установлена. 0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 1 не будет обновлено. У нас в Backports 2.4 (у меня было M2.4+Backports2.4) libapr более новый чем в C3.0 (0.9.7-alt0.M24.1 и 0.9.6-alt1, соответственно)... Бэкпартировать 0.9.7 для Backports3.0? Для себя -- сделать смогу (наверное) готового, для C3.0 -- у меня нет. > > libsubversion требует libapr >= 1:0.9.5-alt0.4, и не указывает явно > требуемую версию libaprutil; возможно, в пакет следует добавить > зависимость на libaprutil версии не ниже, чем использованная при > сборке пакета. PS: Пошлю описание ситуации в Backports: думаю, что обновление D(n)+B(n) до D(n+1) -- должно проходить гладко. По факту -- мы этого не имеем (оказалось, что libapr -- не один пакет, dist-upgrade переживший). -- С уважением. Алексей.