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

[Alexey Tourbin]

On Sun, Mar 20, 2011 at 03:46:56PM +0200, Michael Shigorin wrote:
> 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, а ещё и в сложившейся практике?..

Зависимость была добавлена очень давно, когда версия curl была значительно
ниже (и там могло быть много разных отличий).  Сложившаяся вследствие
этого практика порочна.  Сейчас не существует причины, по которой пакет
libcurl-devel должен требовать libssl-devel.

> Мне тоже обидно такое говорить, но лучше сказать, чем будешь
> думать, что от этого изменения пакет стал лучше, а это не так
> (http://egorfine.com/ru/articles/worse-than-failure/).
> 
> > Я не отслеживаю возникновение "урезанных конфигураций" такого
> > рода, просто нашёл первый подходящий для примера лог сборки.
> > В принципе вся информация открыта.
> 
> Лёш, ну ты ж понимаешь, что это "в принципе" как мёртвому припарки.
> У нас вон куча открытых отчётов repocop, а многие люди наступают
> на описанные там грабли -- файловые конфликты те же.
> 
> Стоит делать так, чтоб использовать репозиторий и работать над
> ним было удобно.  Времени и так не хватает ни на что, а ты его
> предлагаешь потратить его на анализ неформализованных данных
> и даже не говоришь, ради чего.
> 
> По-моему, подобная минимизация сборочных зависимостей имеет ровно
> одно преимущество: облегчение сборочного чрута при прочих равных.
> Но само по себе это времени людей не стоит -- смотри, в случае
> того же strongswan получилось так:
> 
> - ты потратил время на оптимизатор в buildreq;
> - я потратил время на прогон buildreq ради частичных BR;
> - ты потратил время на выкидывание "лишней" зависимости;
> - я потратил время на добавление её назад в другом месте.
> 
> Итоговый результат -- суммарные сборочные зависимости
> в лучшем случае сохранились без изменений, зато потрачена
> стопка твоего и сколько-то моего времени.  На что?
> 
> > Если бы тестовая пересборка была частью сборочной системы,
> > то анализировать эту информацию было бы проще.
> 
> Может, откатим этот набор улучшений до той поры?

Зависимости у *-devel пакетов должны быть исправлены.

Это не новость, в этом направлении уже многое сделано: 1) pkgconfig.req
больше не учитывает Requires.private зависимости; это стало возможным,
потому что 2) сам pkg-config был модифицирован таким образом, что
отсуствие Requires.prviate зависимостей в режиме --cflags больше не
считается ошибкой; 3) добавлен cpp.req, который вытягивает зависимости
из хедеров.