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

[Aleksey Novodvorsky <aen@altlinux.ru>]

24 марта 2011 г. 3:36 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> 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.
> Исправить их не очень сложно.
>
> Некоторые пакеты стали собираться в урезанной конфигурации.  Такие пакеты
> сложнее идентифицировать.  Виновата в этом фирма альт линукс, а вовсе даже
> не Алексей Турбин, т.к. его идея интеграции тестовой пересборки в
> сборочную систему и создания метарепозитория материально-технически
> поддержана не была (хотя разговоров об этом было много).

Она была поддержана, но пока не реализована. Это приоритетное
направление нашей работы, но никаких обещаний по срокам не давалось, а
потому стоит исходить из того, что есть сейчас, а не на то, что мы
ждем завтра.
Не снимая с себя ответственности за невыполнение обоснованных желаний,
надо все же понять, что сейчас делать, а для этого надо оценить
масштаб бедствия сейчас и завтра, если продолжать исправление
devel-пакетов.
Я вижу два варианта:
1. Приостановить исправления devel-пакетов до появления новой техники
в достаточном количестве, обсудить эффестивность частичного отката и
чинить сломанное.
2at: это вовсе не отказ от Вашей работы, а перенос ее на лучшие (у
меня есть основания полагать, что совсем недалекие времена.
2. Продолжать изменения сейчас.

Второй вариант лично мне кажется неприемлемым со всех сторон, кроме
абстрактно-технической. Могу ошибаться, конечно.
Первый вариант требует оценки потенциально воможных последствий и
серьезной поддержки всей команды, невзирая на нынешние и прошлые обиды
и споры. "Чувство локтя", как здесь было сказано.

Наверняка есть иные варианты, предлагайте. Предлагаю не устраивать
сейчас поиск виноватых . Это полезно будет сделать, но лучше при
стабильном Сизифе.


Rgrds, Алексей