[devel] про автоматическое и ручное тестирование пакетов

[Денис Смирнов]

On Wed, Jun 17, 2009 at 09:20:01PM +0300, Michael Shigorin wrote:

MS>>> Не всегда осмысленно оставлять старый сонейм.
MS>>> Например, если его поддержка апстримом закончена.
>> В SharedLibsPolicy описана эта процедура.
MS> Держания неподдерживаемой версии, используемой, скажем,
MS> сетевым софтом?

Да, все очевидно. Поясню на примере:
скажем есть некая библиотека libbugs. И есть два сетевых приложения -- A
и B, которые ее используеют. Так уж получилось, что A мантейнишь ты, а B
мантейню я. Оба приложения сложные, без поллитра в них не разберешься, и
фиксить эти предложения кому-то кроме мантейнера крайне трудоемко.

Теперь представим себе ситуацию -- у libbugs вышла версия с новым soname.
А в версии со старым soname обнаружили критическую багу.

Ты, как сознательный мантейнер, вместе с мантейнером libbugs в shared
task'е радостно исправляешь свой пакет A. А я, как несознательный
мантейнер, уехал на неделю в отпуск. Вы с мантейнером libbugs попытались
починить B но у вас ничего не получилось. Варианты действий:

- ждать моего возвращения из отпуска;
- звонить мне на мобильный с просьбой вернуться из отпуска пораньше;
- вынести B на время из репозитория;
- спокойненько собрать libbugs с новым soname согласно sharedlibspolicy, и
  повесить на B blocker, одновременно отписав мне в почту;

Как ты понимаешь, если будет выбран вариант 3, а при этом приложение B на
самом деле используется всего парой членов тим, да еще и в защищенных
подсетях, то кто-нибудь обидется.

Поэтому лично я являюсь сторонииком 4-го варианта.

А процедура удаления пакета, который уже не используется в
SharedLibsPolicy прописана. Разве что можно еще repocop научить
отстреливать тех кто requires подобны библиотеки.

>> Вопрос -- считаешь ли ты что наличие в репо пакета который
>> требует старый soname и мантейнеру которого нет желания и
>> причин сейчас переезжать на новый поводом для удаления пакета
>> из репо, например? ;)
MS> Нет, если с ним нет cri/blo вроде sec.

Какой срок ты считаешь разумным для отстрела пакета при наличии
critical/block bug'и? Поясню -- без исполнения SharedLibsPolicy пока ты не
острелишь пакет который не фиксят -- не можешь залить фикс для других
пакетов, получается.

>> Второе -- независимо от этого apt если делать переезд игнорируя
>> SharedLibsPolicy склеит ласты на upgrade
MS> Возможно.
>> dist-upgrade.
MS> Маловероятно, для этого пакет-клиент библиотеки должен был
MS> вылететь из сизифа между бранчами или не попасть в новый бранч.
MS> Для важной софтины я предпочту на этой точке задуматься -- брать
MS> старый или поддерживать самому в актуальном состоянии.

Миша, ты исходишь из того что apt поступает _разумно_. А apt поступает не
всегда разумно, и вместо обновления библиотеки иногда предпочитает вынести
пол-системы. Ты ведь неоднократно это наблюдал, когда набираешь apt-get
dist-upgrade а тебе предлагают вместо обновления -- удаления. Так вот
именно для решения _этой_ проблемы SharedLibsPolicy была написана.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090618/f6154b1a/attachment.bin>