[devel] А не создать ли группу @cpan ?

[Michael Bochkaryov]

14 декабря 2009 г. 18:04 пользователь Victor Forsyuk написал:
>
>>> SYA> Это означает и перенос пакетов в git ?
>>>
>>> Это значит, что если кто-то из группы @cpan захочет обновить пакет, и ему
>>> будет лениво собирать srpm -- то он сможет не спросив мантейнера
>>> перенести
>>> из src в git, дв.
>>
>> Давайте сразу договоримся, что этот кто-то из группы @cpan не будет так
>> делать никогда-никогда.
>
> Отсутствие возражений от участников @cpan я воспринимаю как согласие с таким
> полиси. :)

Хм... лично я свои пакеты перетаскиваю в git по мере пересборки.

Может стоит зафиксировать нечто вроде такого:
1. Если в Packager стоит cpan на packages, то перенос сборки в git допускается.
2. В противном случае перенос srpm => git может делать только Packager
(как и смену оного тега на cpan@).

> Поскольку я уже прицелился обновить пару модулей, хочу заранее
> проанонсировать те изменения спеков, которые я планирую применять. Если
> кому-то не нравятся какие-то из них давайте обсудим до, чтобы потом не было
> неудовольства типа "муж пришел и перетрахал все по-своему". :)
>
> 1. Если спек-файл сгенерирован утилитой cpan2rpm он преобразовывается в
> стандартный человеческий вид. Пример моего спека:
> http://sisyphus.ru/ru/srpm/Sisyphus/perl-Locale-US/spec

Согласен, но неплохо бы тогда на wiki вынести описание стандарта.

http://www.altlinux.org/Perl

> 5. Если в пакете были незапакованы man-страницы, то добавляется
> %perl_vendor_man3dir/*.

С man-страницами хорошо бы определиться.
Пробегала раньше рекомендация их выбрасывать, т.к. это генерат из perldoc.

Но perldoc не всегда установлен, да и от рута не работает.
Так что я тоже больше склонен к тому, чтобы упаковывать man'ы.

> Что делать с Packager - у меня нет сложившегося мнения. Наверное стоит
> менять на нового сборщика, если видно, что предыдущий опекун пакета о нем
> подзабыл (по количеству неопакеченых новых версий, давности собранной,
> серьезности изменений за это время). В остальных случаях оставлять.

Для пакетов в @cpan лучше установить в cpan на packages по аналогии с
другими группами.
А если сборщик хочет лично контролировать пакет - тогда и @cpan в acl не будет.

> Подчеркиваю, что я за то, чтобы к пакетам at@ и lav@ применять особые,
> согласованные с ними правила пересборки их перловых пакетов, только бы они
> добавили cpan@ для обновления этих пакетов. Две сотни устаревших модулей на
> двоих - это много. Коллеги, не отказывайтесь от помощи!


-- 
Regards,
Michael Bochkaryov
www.rattler.kiev.ua