[devel] I: viy current schedule on perl, python, java.

[Ivan Zakharyaschev]

On Fri, 13 Jan 2017, Alexey Shabalin wrote:

> 13 января 2017 г., 18:31 пользователь Igor Vlasenko
> <vlasenko на imath.kiev.ua> написал:
>> On Fri, Jan 13, 2017 at 12:32:49PM +0300, Ivan Zakharyaschev wrote:
>>> Понятно. Я думал, что, может быть, отправленные на сборку пакеты просто были
>>> с нуля сгенерированы, раз они не наследуют историю. А оказывается, туда
>>> более тонко были вставлены новые исходники.
>>
>> У меня есть рабочий робот для обновления srpm'ов.
>> Он в сизифе 2 тысячи perl-* обновляет, и его я приспособил и к питону.
>> Обновлял srpm'ы, поэтому и заливал как srpm'ы,
>> пришлось отрывать git.
>
> Мне кажется, в случае python модулей использование srpm оправдано, и
> большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> предполагется их обновление роботом.
> И я готов свои python-пакеты вытащить из git. (не все, есть исключения)

В целом, конечно, согласен. Git имеет смысл, по-моему, для каких-то 
отдельных пакетов, где мейнтейнер хочет вытаскивать отдельные коммиты и 
т.п.

> Многие вещи, которые делал real@ с python-пакетами для меня остаются загадкой.
> Например, pickles подпакеты.

Не знаю толком на счёт pickles, но вот что касается похожей штуки, т.е. 
генерации документации -- я когда разбирался с циклами сборочных 
зависимостей и применял buildreq, обнаружил -- то она неправильно 
генерируется (иногда) из установленных в систему пакетов (предыдущей 
версии!).

Я запланировал, чтобы решить и проблему минимизации сборочных зависимостей 
(для массового обновления), и эту неправильность, собирать документацию 
отдельно. (И pickles, возможно.)

Пока был Git, думал, можно будет в тот же спек правила написать, но по 
переменным gear из тега выбирать, собираем ли мы сам пакет или 
документацию.

А так можно будет помимо основных srpm делать просто rebuild srpm-а для 
сборки документации. Версию он подставит из сборочной среды, и править 
srpm не надо будет каждый раз.

-- 
Best regards,
Ivan