[devel] at@, не ломай сизиф

[Michael Shigorin]

On Sun, Mar 20, 2011 at 04:26:27PM +0300, Alexey Tourbin wrote:
> > (похоже, раньше libcurl-devel или libldap-devel вытягивал
> > libssl-devel)
> Да, libcurl-devel требовал libssl-devel, причем эта зависимость была
> указана в спекфайле вручную.  OpenSSL используется только в реализации,
> а на уровне API никак не упоминается.  Поэтому я всего лишь убрал
> лишнюю зависимость из спекфайла, вследствие чего пакет libcurl-devel
> стал лучше. Обидно слышать, что я ломаю сизиф.

А с майнтейнером не советовался, из каких соображений он туда
эту зависимость прописывал руками?  Может, дело не в формальном
API, а ещё и в сложившейся практике?..

Мне тоже обидно такое говорить, но лучше сказать, чем будешь
думать, что от этого изменения пакет стал лучше, а это не так
(http://egorfine.com/ru/articles/worse-than-failure/).

> Я не отслеживаю возникновение "урезанных конфигураций" такого
> рода, просто нашёл первый подходящий для примера лог сборки.
> В принципе вся информация открыта.

Лёш, ну ты ж понимаешь, что это "в принципе" как мёртвому припарки.
У нас вон куча открытых отчётов repocop, а многие люди наступают
на описанные там грабли -- файловые конфликты те же.

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

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

- ты потратил время на оптимизатор в buildreq;
- я потратил время на прогон buildreq ради частичных BR;
- ты потратил время на выкидывание "лишней" зависимости;
- я потратил время на добавление её назад в другом месте.

Итоговый результат -- суммарные сборочные зависимости
в лучшем случае сохранились без изменений, зато потрачена
стопка твоего и сколько-то моего времени.  На что?

> Если бы тестовая пересборка была частью сборочной системы,
> то анализировать эту информацию было бы проще.

Может, откатим этот набор улучшений до той поры?

> > > Создавать бранч в ближайшее время не рекомендуется.
> > Если исправлять молча в одностороннем порядке, то и
> > к осени можно не управиться с разгребанием последствий.
> Проще ничего не делать и в час X объявить сизиф стабильным.
> Вследствие крайней нужды в стабильном бранче.

Это другая крайность. :)

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