[devel] Q: automated update of CPAN perl modules

[Igor Vlasenko]

On Wed, Jul 21, 2010 at 12:57:47AM +0400, Alexey Tourbin wrote:
> > написать робота, который обновит сотню-другую пакетов
> > (были бы acl), и который потом можно было бы регулярно,
> > скажем, ежемесячно, запускать.
> 
> Если робот очень хороший (вплоть до того, что наделен искусственным
> интеллектом), то имеет смысл большую часть перловых пакетов обновлять
> автоматически.  В принципе это касается не только перловых пакетов.
> Поскольку кому охота там одно и то же вручную ковыряться whatever.

Роботы снижают механическую работу, не более.
Скажем, без робота для поддержки 2000 перловых пакетов
понадобился бы Алексей Турбин или другой майнтайнер его уровня
+ 40 помощников, вникающих в проблему на уровне Васи Пупкина.
А с роботом, чем умнее робот, тем меньше помощников нужно.
В идеале автоматизация должна дойти до того, что

1) в помощниках не будет необходимости (да, запустить робота 
сможет и Вася Пупкин, но вот исправить за роботом сможет только 
кто-то владеющий вопросом на уровне Алексея Турбина)

2) после робота будет оставаться только интересные проблемы,
требующие обдумывания, поэтому с роботом работать будет намного 
интереснее. Он как бы фильтрует тривиальные проблемы.

> Но роботы у нас не шибко-то умные (да и ...).  Поэтому приходится
> задумываться, как не въехать на полной скорости в бетонный столб.

робота можно и нужно постоянно улучшать.
Я текущего написал на коленке, больше как иллюстрация
к выступлению в Переяславле, чтобы утверждения о 
автоматизации не показались надуманными или голословными.
Если сравнивать его с cpan2rpm, то он еще код-младенец:
wc -l CPANupdate.pl /usr/bin/cpan2rpm
  144 CPANupdate.pl
 2088 /usr/bin/cpan2rpm

> Вот, например, стандартная грабля с версией:
> Была версия 0.15, стала версия 0.17016.  Что сделает очень хороший
> робот, если следующая версия станет 0.18?

сейчас робот лохонется, так как он пользуется evrcmp, 
а rpmevrcmp 0.17016 0.18=1. Но его можно улучшить,
если написать собственный sub perlvercmp и при распознавании
такой ситуации дополнительно инкрементировать Serial или Epoch,
из того, что найдено в спеке.
 
> Есть другие тонкости - например, как обновлять BuildRequires?

В >85% случаев их обновлять не понадобилось,
а в оставшихся случаях добавил руками, что было все же удобнее,
чем с нуля: под рукой был пакет или git с обновленными исходниками, 
версией и changelog'ом, и его лог пересборки (неудавшейся).

Но опять же, если подойти к роботу серьезно, 
то можно ежедневно генерировать из базы репокопа 
таблицу соответствия перловых модулей перловым rpm пакетам.
пройдясь grep по .pm/.t файлам в поиске use директив,
получим список модулей. С пом. таблицы он переводится в
список BuildRequires:. Сравнить его с имеющимся.
А уже обновить спек - не проблема.

И этот механизм также было бы скрестить с cpan2rpm.

Т.е. трюкам робота обучить можно.

Там возникла более важная проблема,
которую можно решить, и нужно решать,
но нужна помощь сообщества. 
Это стандартизация работы с gear+git репозиториями,
я в отдельном письме напишу.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine