[devel] at@, не ломай сизиф
Michael Shigorin
mike на osdn.org.ua
Вс Мар 20 13:46:56 UTC 2011
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/
Подробная информация о списке рассылки Devel