[devel] правильные зависимости

[Alexey Tourbin]

On Thu, Mar 24, 2011 at 01:17:13AM +0200, Michael Shigorin wrote:
> On Thu, Mar 24, 2011 at 01:03:28AM +0300, Alexey Tourbin wrote:
> > > > Если рациональные аргументы не интересуют
> 
> Сделай мне лично одолжение -- прочти вот эту статью:
> http://egorfine.com/ru/articles/worse-than-failure/

Прочитал.  Там написано, что надо признавать свои ошибки.
Исправление зависимостей у *-devel пакетов ошибкой не является.
В техническом отношении, по крайней мере.

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

Правильные зависимости - это все те и только те зависимости, которые
обеспечивают работоспособность пакета, что обычно означает возможность
использовать по прямому назначению его содержимое.

Факторы работоспособности *-devel пакетов:
1) Возможность включать хедеры (т.е. должны быть зависимости на хедеры,
которые включаются в свою очередь).
2) Возможность вызывать pkg-config (т.е. должны быть зависимости, которые
обеспечивают Requires в *.pc файлах, иначе pkg-config откажется давать
результат).
3) Возможность линковки.  Если в .pc:Libs: указаны дополнительные
библиотеки, то они должны быть поддержаны соответствующими зависимостями.
Впрочем, настоящая необходимость указывать дополнительные библиотеки в Libs:
возникает очень редко - дополнительные библиотеки в Libs: чаще всего
находятся по ошибке, тогда как на самом деле им место в Libs.private.

Все зависимости, которые не являются правильными, являются неправильными.

> > Если от исправления зависимостей ломаются другие пакеты, то у
> > других пакетов тоже неправильные зависимости, и они тоже должны
> > быть исправлены.
> 
> Смотри, это можно сделать двояко.  Либо разгребя дорогу перед
> теми, кто может добраться и помочь -- либо распинав их со своей
> дороги и... и тогда своими руками.
> 
> Мне кажется, что _правильным_ способом реализации той расчистки,
> что ты задумал и начал делать не с того конца -- был бы такой:
> 
> 1) анонс задумки в devel@;
> 2) модификация buildreq для исключения случайных потерю полных BR;
> 3) анализ сизифа на предмет предположительно лишних зависимостей;
> 4) обсуждение полученного списка удалений по части особых случаев
>    ("так задумано для...") и документирование их в спеках;
> 5) прогон buildreq -u по затрагивающимся пакетам (хорошо бы
>    заодно и версии/spec cleanup/патчи в апстрим...);
> 6) когда хотя бы большая часть (пусть 80%) затронутых пакетов
>    получили зафиксированные полные сборочные зависимости,
>    можно вырезать лишние из графа;
> 7) потихоньку фиксить остатки, имея под рукой (на вики,
>    здесь, лишь бы где-то был) текущий список оставшегося;
> 8) когда пыль начнёт оседать, можно открутить дефолт для
>    buildreq назад к оптимизирующему (хотя IMHO хранить полный
>    список в закомментированном виде весьма полезно);
> 9) и хорошо бы подвести итоги -- что было, что стало,
>    чего добились и что по дороге оказалось иначе.
> 
> Такой подход куда более нудный, чем с шашкой в бой, но скажи,
> в каких пунктах неправ и было бы предсказуемо хуже?  Или тебе
> просто такое неприемлемо?

Это всё долго и глупо.  По сути, надо сделать две вещи.  Сначала
исправить *-devel пакеты.  Потом исправить пакеты, которые из-за
этого сломались.  Пакеты, которые явно сломались, видно в beehive_status.
Исправить их не очень сложно.

Некоторые пакеты стали собираться в урезанной конфигурации.  Такие пакеты
сложнее идентифицировать.  Виновата в этом фирма альт линукс, а вовсе даже
не Алексей Турбин, т.к. его идея интеграции тестовой пересборки в
сборочную систему и создания метарепозитория материально-технически
поддержана не была (хотя разговоров об этом было много).

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

> > Сохранине статуса-кво перед созданием нового бранча могло бы
> > иметь некоторой смыл, хотя к рациональным аргументам это не
> > отнсится.
> 
> Rationale: стабилизировать реальней то, от чего знаешь,
> чего ожидать (проверено собственноручно на 4.0/branch
> и Terminal 4.0 -- по качеству он, похоже, вышел почти
> как Master 2.4, если судить по отзывам).
> 
> Contra: сделать вагон бинарно несовместимых изменений сразу после
> бранча -- значит в который раз напороться на повышенные обяза^W
> в смысле кровопотери по техническому бэкпортированию.
> 
> В любом случае очень надеюсь, что бранч не свалится как снег
> на голову.