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

Michael Shigorin mike на osdn.org.ua
Ср Мар 23 23:17:13 UTC 2011


On Thu, Mar 24, 2011 at 01:03:28AM +0300, Alexey Tourbin wrote:
> > > Если рациональные аргументы не интересуют

Сделай мне лично одолжение -- прочти вот эту статью:
http://egorfine.com/ru/articles/worse-than-failure/

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

Определи правильные зависимости, пожалуйста.  Не докапываюсь,
просто когда подходит к трактовке слов, лучше сразу уточнить.

> Если от исправления зависимостей ломаются другие пакеты, то у
> других пакетов тоже неправильные зависимости, и они тоже должны
> быть исправлены.

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

Мне кажется, что _правильным_ способом реализации той расчистки,
что ты задумал и начал делать не с того конца -- был бы такой:

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

Такой подход куда более нудный, чем с шашкой в бой, но скажи,
в каких пунктах неправ и было бы предсказуемо хуже?  Или тебе
просто такое неприемлемо?

> Сохранине статуса-кво перед созданием нового бранча могло бы
> иметь некоторой смыл, хотя к рациональным аргументам это не
> отнсится.

Rationale: стабилизировать реальней то, от чего знаешь,
чего ожидать (проверено собственноручно на 4.0/branch
и Terminal 4.0 -- по качеству он, похоже, вышел почти
как Master 2.4, если судить по отзывам).

Contra: сделать вагон бинарно несовместимых изменений сразу после
бранча -- значит в который раз напороться на повышенные обяза^W
в смысле кровопотери по техническому бэкпортированию.

В любом случае очень надеюсь, что бранч не свалится как снег
на голову.

> Я вообще занимаюсь разработкой, кстати.  А не только излагаю
> свое веские имхи.

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

А ещё кто-то "занимался разработкой", прилепив к регулирующим
стержням РБМК "экономичные" довески, которые поглощали хуже воды.
И неожиданно разогнали реактор при его вроде бы как останове из
непредвиденного режима.

Понимаешь, экономичность установки не стоила здоровья людей,
в том числе и моих близких.

Так и тут.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/


Подробная информация о списке рассылки Devel