[devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Alexey Morozov]

Здравствуйте!

Имеем http://git.altlinux.org/tasks/index/sisyphus/failed/68729/build/400/i586/log

Пакет (kdevelop) собирается хорошо, однако, при попытке его установки происходит ошибка
libkdev4cmakecommon.so>= set:mgEG3imLZ9Xjq7yCq68U5lK6pjHRJ8oUXGqZJRXc2OibNKQlZo1KH7X4IvF56TUonEZ8VyAe42LDX8gS76xyryImKSxM66oUEQqGfxsNqO30J1eOmGA6Z0yLLnB5A6Ke0zGC0

а собирающийся _в рамках этой же сборки_ kdevelop-libs предоставляет:
Provides: libkdev4cmakecommon.so = set:mdRMryV7HjpwPhy64p0ghRnTlb8StEYCDkJK3VCRdPewbZwKSk3s1s1nIJcCeI7rlrPmMQFUIdFZq1mRaCSpngDStECW090bGLHeQZshqrvZKwyceLQ8OuKdl4qj3vunJemTQM5lpj5sHKdsqK3KU8DZx29eu8zLImfymlzwXWruOvNeK5vLTLCL5dIDZqJASEY32SI9fbdNK9QRo5MYmgxbY0w4wmhWZ83SRZvAwxV1gN3bCWBBiqCAsNkVQIPO3cTn6rE6Nqujc0OUxirgnCOBbi7iD4PmCssWAfs226GBl7SZywPVE4h8ZogtwqePl3xfh9t3iSSCskFIhSIy1IIrT76MaGhNuNKf7TXu4He1lsVeGHCb3PIibZerqKKGKPKm912P7JRsgHAg2QLG84fjkdQhRNic8G2Kv6EautmL4b7VkMgMEzvNG0e0bESWUDuOFQZF53ovgYxbnIRb0wrAjTLXDy1GQqOFx6OZk4WWU8A4BkAcUX7ObUkGZec3NZK5tjkb0GYdciwMz2zj2b4D8F5lHAbxgAgVIbdcMyNqZbiYfRYdvKcZbFMZn0NgZ9oJoL83oc1gCwkTOnZo8Mwme7366kdmeuq0BGr6lMInZtxRLR7U9FU9V5PTzn0ru90A7C8a9UZhf2cboTlnzZwy4x8tyuE8x1ojhLy5kc2p6IvqiJHAhznO38V1Du

и так со всеми .so-шками, входящими в kdevelop-libs.

Товарищи учёные, как говорится, объясните явление!

P.S. Два дня назад в локальном хэшере это, кажется, собиралось и даже дист-агрейдилось.

Re: [devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On Fri, Apr 06, 2012 at 06:21:57PM +0700, Alexey Morozov wrote:
> Имеем http://git.altlinux.org/tasks/index/sisyphus/failed/68729/build/400/i586/log
> 
> Пакет (kdevelop) собирается хорошо, однако, при попытке его установки происходит ошибка
> libkdev4cmakecommon.so>= set:mgEG3imLZ9Xjq7yCq68U5lK6pjHRJ8oUXGqZJRXc2OibNKQlZo1KH7X4IvF56TUonEZ8VyAe42LDX8gS76xyryImKSxM66oUEQqGfxsNqO30J1eOmGA6Z0yLLnB5A6Ke0zGC0
> 
> а собирающийся _в рамках этой же сборки_ kdevelop-libs предоставляет:
> Provides: libkdev4cmakecommon.so = set:mdRMryV7HjpwPhy64p0ghRnTlb8StEYCDkJK3VCRdPewbZwKSk3s1s1nIJcCeI7rlrPmMQFUIdFZq1mRaCSpngDStECW090bGLHeQZshqrvZKwyceLQ8OuKdl4qj3vunJemTQM5lpj5sHKdsqK3KU8DZx29eu8zLImfymlzwXWruOvNeK5vLTLCL5dIDZqJASEY32SI9fbdNK9QRo5MYmgxbY0w4wmhWZ83SRZvAwxV1gN3bCWBBiqCAsNkVQIPO3cTn6rE6Nqujc0OUxirgnCOBbi7iD4PmCssWAfs226GBl7SZywPVE4h8ZogtwqePl3xfh9t3iSSCskFIhSIy1IIrT76MaGhNuNKf7TXu4He1lsVeGHCb3PIibZerqKKGKPKm912P7JRsgHAg2QLG84fjkdQhRNic8G2Kv6EautmL4b7VkMgMEzvNG0e0bESWUDuOFQZF53ovgYxbnIRb0wrAjTLXDy1GQqOFx6OZk4WWU8A4BkAcUX7ObUkGZec3NZK5tjkb0GYdciwMz2zj2b4D8F5lHAbxgAgVIbdcMyNqZbiYfRYdvKcZbFMZn0NgZ9oJoL83oc1gCwkTOnZo8Mwme7366kdmeuq0BGr6lMInZtxRLR7U9FU9V5PTzn0ru90A7C8a9UZhf2cboTlnzZwy4x8tyuE8x1ojhLy5kc2p6IvqiJHAhznO38V1Du
> 
> и так со всеми .so-шками, входящими в kdevelop-libs.
> 
> Товарищи учёные, как говорится, объясните явление!

Создаётся впечатление, что apt запутывается в имеющейся в этом задании
мешанине пакетов, содержащих вроде бы одни и те же библиотеки, но
разных версий (kdevelop-libs, kdevelop-pre4.4-libs, и ещё откуда-то
берётся kdevelop-unstable-libs).  Возможно, поможет добавление в пакет
kdevelop-base явной зависимости на kdevelop-libs вида

  Requires: %name-libs = %epoch:%version-%release

(и аналогично в kdevelop-pre4.4-base).  Вообще rpm по поводу
отсутствия этой зависимости выдаёт предупреждения:

warning: kdevelop-base: non-strict dependency on kdevelop-libs

warning: kdevelop-pre4.4-base: non-strict dependency on kdevelop-pre4.4-libs

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Alexey Morozov]

Доброго утра!

On 6 апреля 2012 23:35:12 Sergey Vlasov wrote:
> Создаётся впечатление, что apt запутывается в имеющейся в этом задании
> мешанине пакетов, содержащих вроде бы одни и те же библиотеки, но
> разных версий (kdevelop-libs, kdevelop-pre4.4-libs, и ещё откуда-то
> берётся kdevelop-unstable-libs).  Возможно, поможет добавление в пакет
> kdevelop-base явной зависимости на kdevelop-libs вида
> 
>   Requires: %name-libs = %epoch:%version-%release

Ну, после подчистки задания (оставил только kdevelop-4.3.0 & Co) и выставления
явной зависимости на kdevelop-libs, диагностика при инсталляции несколько
изменилась, теперь я вообще отказываюсь что-либо понимать :)

При попытке автоматической инсталляции -debuginfo пакетов выдаётся такое
http://git.altlinux.org/tasks/index/sisyphus/failed/68729/logs/events.6.1.log :

The following extra packages will be installed:
  kdevelop-base kdevelop-common kdevelop-libs kdevelop-okteta
  kdevelop-okteta-debuginfo kdevplatform kdevplatform-libs
  kdevplatform-libs-debuginfo
The following packages will be REPLACED:
  kdevplatform-unstable-common (by kdevplatform-libs)
The following packages will be REMOVED:
  libkdevplatformdebugger4-unstable libkdevplatformdebugger4-unstable-debuginfo
  libkdevplatformdocumentation4-unstable
  libkdevplatformdocumentation4-unstable-debuginfo
  libkdevplatforminterfaces4-unstable
  libkdevplatforminterfaces4-unstable-debuginfo
  libkdevplatformlanguage4-unstable libkdevplatformlanguage4-unstable-debuginfo
  libkdevplatformoutputview4-unstable
  libkdevplatformoutputview4-unstable-debuginfo
  libkdevplatformproject4-unstable libkdevplatformproject4-unstable-debuginfo
  libkdevplatformshell4-unstable libkdevplatformshell4-unstable-debuginfo
  libkdevplatformutil4-unstable libkdevplatformutil4-unstable-debuginfo
  libkdevplatformvcs4-unstable libkdevplatformvcs4-unstable-debuginfo
  libsublime4-unstable libsublime4-unstable-debuginfo
The following NEW packages will be installed:
  kdevelop-base kdevelop-common kdevelop-libs kdevelop-okteta
  kdevelop-okteta-debuginfo kdevplatform kdevplatform-libs
  kdevplatform-libs-debuginfo
0 upgraded, 8 newly installed, 1 replaced, 20 removed and 0 not upgraded.
Need to get 0B/17.1MB of archives.
After unpacking 15.1MB of additional disk space will be used.

В общем, пока как и ожидалось. Однако, следом:
Executing RPM (hsh-rpmi-print-files -e -r /tmp/.private/bee9/hasher/aptbox --nodeps)...
hsh-rpmi-print-files: cannot erase packages: libkdevplatformshell4-unstable-debuginfo libsublime4-unstable-debuginfo libkdevplatformshell4-unstable libsublime4-unstable libkdevplatformvcs4-unstable-debuginfo libkdevplatformvcs4-unstable libkdevplatformproject4-unstable-debuginfo libkdevplatformlanguage4-unstable-debuginfo libkdevplatformdebugger4-unstable-debuginfo libkdevplatformutil4-unstable-debuginfo libkdevplatformproject4-unstable libkdevplatformlanguage4-unstable libkdevplatformdebugger4-unstable libkdevplatformutil4-unstable libkdevplatformoutputview4-unstable-debuginfo libkdevplatformoutputview4-unstable libkdevplatformdocumentation4-unstable-debuginfo libkdevplatforminterfaces4-unstable-debuginfo libkdevplatformdocumentation4-unstable libkdevplatforminterfaces4-unstable

Чтобы rpm -e --nodeps не выносил пакеты, а довольствовался лишь мозгом - такое,
признаться, вижу впервые :)

АМ

Re: [devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

On Sat, Apr 07, 2012 at 11:09:50AM +0700, Alexey Morozov wrote:
> Ну, после подчистки задания (оставил только kdevelop-4.3.0 & Co) и выставления
> явной зависимости на kdevelop-libs, диагностика при инсталляции несколько
> изменилась, теперь я вообще отказываюсь что-либо понимать :)
> 
> При попытке автоматической инсталляции -debuginfo пакетов выдаётся такое
> http://git.altlinux.org/tasks/index/sisyphus/failed/68729/logs/events.6.1.log :
[...]
> Executing RPM (hsh-rpmi-print-files -e -r /tmp/.private/bee9/hasher/aptbox --nodeps)...
> hsh-rpmi-print-files: cannot erase packages: libkdevplatformshell4-unstable-debuginfo libsublime4-unstable-debuginfo libkdevplatformshell4-unstable libsublime4-unstable libkdevplatformvcs4-unstable-debuginfo libkdevplatformvcs4-unstable libkdevplatformproject4-unstable-debuginfo libkdevplatformlanguage4-unstable-debuginfo libkdevplatformdebugger4-unstable-debuginfo libkdevplatformutil4-unstable-debuginfo libkdevplatformproject4-unstable libkdevplatformlanguage4-unstable libkdevplatformdebugger4-unstable libkdevplatformutil4-unstable libkdevplatformoutputview4-unstable-debuginfo libkdevplatformoutputview4-unstable libkdevplatformdocumentation4-unstable-debuginfo libkdevplatforminterfaces4-unstable-debuginfo libkdevplatformdocumentation4-unstable libkdevplatforminterfaces4-unstable
> 
> Чтобы rpm -e --nodeps не выносил пакеты, а довольствовался лишь мозгом - такое,
> признаться, вижу впервые :)

На самом деле hsh-rpmi-print-files в принципе не может удалять пакеты
и отказывается делать это.  Вопрос в том, откуда на этом шаге вообще
может возникать запрос на удаление пакетов.

Вообще при проверке check-install установка пакетов в chroot с базовой
системой выполняется в два этапа:

1) Устанавливаются все пакеты, которые требуются по зависимостям для у
   становки тестируемого пакета, за исключением самого этого пакета:

     hsh-install -- "$N=$EVR" "$N-"

2) Устанавливается сам тестируемый пакет:

     hsh-install -- "$N=$EVR"

В данном случае при выполнении второй установки обнаруживается, что во
время первой установки в chroot оказались установлены пакеты
*-unstable не от той версии kdevplatform, которая нужна (да и вместо
kdevplatform-libs установился kdevplatform-unstable-common).  Каким
образом такое могло произойти - apt его знает.

Насколько я понял, все эти пакеты *-unstable предполагалось в конечном
итоге удалить из Сизифа; тогда, возможно, проще будет сначала их
удалить явным образом, а потом уже собирать новую версию (попробовать
сначала в одном задании, если не пройдёт с похожими ошибками -
придётся сначала выносить отдельным заданием).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Alexey Morozov]

Добрый вечер!

On 7 апреля 2012 18:03:56 Sergey Vlasov wrote:

> Насколько я понял, все эти пакеты *-unstable предполагалось в конечном
> итоге удалить из Сизифа; тогда, возможно, проще будет сначала их
> удалить явным образом, а потом уже собирать новую версию (попробовать
> сначала в одном задании, если не пройдёт с похожими ошибками -
> придётся сначала выносить отдельным заданием).

Ну, здесь есть два аспекта. Первое - я не совсем понимаю, как удалять пакеты 
из Сизифа:

for dp in libkdevplatformshell4-unstable-debuginfo \
   libsublime4-unstable-debuginfo libkdevplatformvcs4-unstable-debuginfo \
   libkdevplatformproject4-unstable-debuginfo \
   libkdevplatformlanguage4-unstable-debuginfo \
   libkdevplatformdebugger4-unstable-debuginfo \
   libkdevplatformutil4-unstable-debuginfo \
   libkdevplatformoutputview4-unstable-debuginfo \
   libkdevplatformdocumentation4-unstable-debuginfo \
   libkdevplatforminterfaces4-unstable-debuginfo;
do
   ssh git.alt build del $dp;
done

new task #68928: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package 
`libkdevplatformshell4-unstable-debuginfo' from `sisyphus'
removing task #68928 ... done
new task #68929: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package `libsublime4-
unstable-debuginfo' from `sisyphus'
removing task #68929 ... done
new task #68930: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package 
`libkdevplatformvcs4-unstable-debuginfo' from `sisyphus'
removing task #68930 ... done

Я так понимаю, удалить отдельные подпакеты нельзя? И как это сделать в рамках 
одной транзакции со сборкой?

Второй момент связан вот с чем. Да, действительно, схема со стабильным и 
нестабильным kdevelop оказалась не слишком удачной, и в 4.3.0 я хотел удалить 
{kdevelop,kdevplatform}-unstable-*. Однако, совсем отказываться от пре-релизов 
тоже не хотелось бы, в 4.3.60+ уже сейчас есть всякие заманушки. Кроме этого, 
я считаю важным, что установленные пакеты пре-релизных версий не должны 
автоматически апгрейдиться до следующего пре-релиза. Например, если у человека 
установлен, например, пакет kdevelop-4.2.80 (с соотв. kdevplatform), то при 
появлении в репозитории kdevelop-4.3.0 и kdevelop-4.3.60 dist-upgrade должен 
происходить до 4.3.0, а не до 4.3.60 (и в локальном хэшере так и было, чес-
слово :)).

Поэтому я решил, что нестабильные сборки будут нести в имени некоторый 
уникальный для данной нестабильной ветки суффикс (для 4.3.60+ это -pre4.4), а 
следующая стабильная версия, когда она будет готова, должна такие пакеты 
обсолетить. Помимо этого, соотв. пакеты должны "во веки веков" обсолетить ещё 
и {kdevelop,kdevplatform}-unstable

Поэтому переводить ситуацию целиком на ручное управление очень не хочется. Но, 
с другой стороны, запихнуть в Sisyphus стабильный kdevelop тоже актуально.

С уважением,
Алексей Морозов

Re: [devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

On Sat, Apr 07, 2012 at 10:38:54PM +0700, Alexey Morozov wrote:
> Добрый вечер!
> 
> On 7 апреля 2012 18:03:56 Sergey Vlasov wrote:
> 
> > Насколько я понял, все эти пакеты *-unstable предполагалось в конечном
> > итоге удалить из Сизифа; тогда, возможно, проще будет сначала их
> > удалить явным образом, а потом уже собирать новую версию (попробовать
> > сначала в одном задании, если не пройдёт с похожими ошибками -
> > придётся сначала выносить отдельным заданием).
[...]
> Я так понимаю, удалить отдельные подпакеты нельзя? И как это сделать в рамках 
> одной транзакции со сборкой?

Удаление производится по имени исходного пакета, удаляются все
собранные из него бинарные пакеты.

Добавление запроса на удаление пакета в задание:

  ssh git.alt task add [<task_id> [<before_subtask_id>]] del <package>

Или от этого unstable зависит что-то важное, что не хотелось бы
удалять?  Хотя, если удалять в том же задании, в котором собирается
новая версия, заменяющая пакет, такое задание должно пройти.

> Второй момент связан вот с чем. Да, действительно, схема со стабильным и 
> нестабильным kdevelop оказалась не слишком удачной, и в 4.3.0 я хотел удалить 
> {kdevelop,kdevplatform}-unstable-*. Однако, совсем отказываться от пре-релизов 
> тоже не хотелось бы, в 4.3.60+ уже сейчас есть всякие заманушки. Кроме этого, 
> я считаю важным, что установленные пакеты пре-релизных версий не должны 
> автоматически апгрейдиться до следующего пре-релиза. Например, если у человека 
> установлен, например, пакет kdevelop-4.2.80 (с соотв. kdevplatform), то при 
> появлении в репозитории kdevelop-4.3.0 и kdevelop-4.3.60 dist-upgrade должен 
> происходить до 4.3.0, а не до 4.3.60 (и в локальном хэшере так и было, чес-
> слово :)).
> 
> Поэтому я решил, что нестабильные сборки будут нести в имени некоторый 
> уникальный для данной нестабильной ветки суффикс (для 4.3.60+ это -pre4.4), а 
> следующая стабильная версия, когда она будет готова, должна такие пакеты 
> обсолетить. Помимо этого, соотв. пакеты должны "во веки веков" обсолетить ещё 
> и {kdevelop,kdevplatform}-unstable

При такой схеме в стабильных версиях будут постепенно накапливаться
Obsoletes на -preX.Y.

> Поэтому переводить ситуацию целиком на ручное управление очень не хочется. Но, 
> с другой стороны, запихнуть в Sisyphus стабильный kdevelop тоже актуально.

Возможно, проблема сейчас возникает из-за недостаточно жёстких
зависимостей в старом unstable (типа той, про которую выдавалось
предупреждение при сборке новых пакетов).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]