Re: [devel] perl upgrade

[Alexey Tourbin <at@altlinux.ru>]

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

On Sat, Mar 13, 2010 at 08:41:37PM +0200, Igor Vlasenko wrote:
> On Sat, Mar 13, 2010 at 08:52:51PM +0300, Alexey Tourbin wrote:
> > > В принципе, у меня есть рабочее решение.
> > > perl-RPM-Convert (RPM::Convert::Generic)
> > > приводит спеки в соответствие с нашими требованиями,
> > > выбрасывая часть устаревших вызовов из %post
> > > и конвертируя их альтернативы в наши.
> > 
> > Я с некоторой иронией написал про конвертацию пакетов из федоры,
> > хорошо скрываемой.  Какой тогда смысл что-то делать, если проще
> > равняться на американскую фирму редхат?  А одна только конвертация
> > никакой добавленной стоимости не создаёт.
> 
> В каждой шутке есть доля правды. Конвертация это только 
> помощник, например, в java я поверх конвертации еще 
> делаю кучу работы, которую не сделали и в Федоре, и в JPackage.

А как совместить предыдущую кучу работы и очередную порцию изменений
в федоровских пакетах?  Если это разовая конвертация то это неинтересно.
А автоматически совмещать изменения можно только в простейших случаях.

Хотя вот есть такие казусы что например импортируется федоровский
src.rpm пакет и при этом существуют нетривиальные локальные изменения.
http://git.altlinux.org/gears/e/elfutils.git
Но это уже такой высший пилотаж.

> Но это позволяет работать с пакетами на более высоком, 
> так сказать, генеральском, уровне, по сравнению с ковырянием 
> с каждым отдельным пакетом. Можно делать высокоуровневые 
> вещи, вроде "передислоцироваться в Шиловичи", а уже роботы
> будут орать отдельным пакетам "подъем, стройся" и т.д., 
> что у робота в программе записано.
> Вместо того, чтобы бегать и командовать за каждого сержанта.
> 
> Взять, например, тот же CPAN. Легко (мне, по крайней мере)
> написать два робота, один из которых будет выдавать отчет,
> что нового в CPAN'е, а другой с разрешения человека 
> будет генерировать обновленные версии rpm пакетов 
> и отправлять их в hasher/incoming.

Лишним в этой цепочке оказывается только человек.  Впрочем, можно
исходить из того, что люди собирают пакеты вслепую - то есть не
просматривают изменения в исходном коде, а сразу пробуют собрать
пакет с новым тарболлом.  Оценку этой деятельности сейчас давать
нет смысла, просто вот допустим есть то что есть.

Тогда чтобы дистростроение было более устойчивым (к ошибкам
мейнтейнеров), нужны автоматические стабилизаторы.  То есть когда
подаёшь на вход дефектные пакеты, то нужно чтобы автоматическое
тестирование их отловило.

Так вот, одна из парадигм дистростроения - особенно соблазнительная
в нашем случае - это полуавтоматическая сборка пакетов при жесточайшем
автоматическом тестировании.  То есть заранее известно что мейнтейнер
это не спецаилист, а он просто пытается подобрать работающую комбинацию
тарболлов/пакетов.  А система отсеивает нерабочие комбинации.

Это я так, рассуждаю.

> Неужели наличие таких роботов-помощников будет чем-то умалять
> ценность работы Алексея Торбина? 
> Ведь они возьмут на себя только черновую часть.

Алексей Турбин не знает зачем он нужен.  И что дальше надо делать.
Ситуация представляется ему что как-то невесело.

> Это можно сравнить со сборкой ядер.
> Любая обезьяна может собрать ядро: tar xzf и вперед.
> Но чем ядра от vsu@ отличаются от ядер обезьяны?
> Тем, что vsu@ знал, что и когда собирать.

Ну да, в какой комбинации подбирать разные тарболлы и патчи. :)

> Знание, опыт в чистом виде.
> 
> А такая система позволила бы при сравнимых 
> усилиях сопровождать в Сизифе на порядок больше 
> перловых модулей, чем есть там сейчас.

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