>>> Список уникальных мегафич в студию! Желательно в сравнении с.
>> Управление флагами сборки удобное. Быстро и удобно можно посмотреть, изменить, посмотреть
>> что измениться, при надобности скорректировать, и так до достижения удовлетворяющего результата.
> bmake show-options
> bmake show-vars VARNAMES='DEPENDS BUILD_DEPENDS'
> bmake show-vars VARNAMES='DEPENDS BUILD_DEPENDS' PKG_OPTIONS.pulseaudio='-x11'
> и т.д. Или это то, что нужно, или уточни детали.глобально pulseaudio включен, но для пакетов foo & bar выключен.
0 cheusov>nih search -I DEPENDS:w:pulseaudio
devel/SDL
- Simple DirectMedia Layer, a cross-platform multimedia library
0 cheusov>
это будут пакеты которые сейчас зависят от pulseaudio или же так мейнтейнер задумал?
(например, linphone может быть собран без поддержки pulseaudio и зависимости не иметь).
>> А если я поменяю пару флагов в какой-нить утилитке, что вытянется по
>> новым зависимостям? С какими флагами?
> см. выше
можно подробнее?
Y с +foo зависит X с +bar. X в системе уже установлен, но с -bar.
Пересоберёт X(и все его уже установленные зависимости)?
>> Да, не без своих проблем, но портам до него как до Луны раком.
> ...и желательно без подобных аналогий.
1)параллельная сборка(X зависит от Y,Z,W которые не установлены. Y & Z независимы, потому их можно собирать параллельно).
2)фоновый фетч в процессе сборки(пока собирается boost/openoffice мы уже вытянули исходники kdelibs со всеми зависимостями)
3)сборка в песочнице
4)контрольные суммы для Makefile
5)фетч под специальным ограниченным пользователем
6)зависимости с учётом флагов(REQUIRED_USE)
7)multiversion(несколько gcc/jvm/etc в рамках одной системы).
8)несколько версий пакета в дереве(gcc-4.5.2, gcc-4.6.1,etc)
9)поддержка профилей(hardened/desktop/server)
10)наличие стабильных(на данной архитектуре с т.з. мейнтейнера) версий
11)виртуальные пакеты(Существуют также пакеты, выполняющие одни и те же функции, но отличающиеся в реализации. Например metalogd, sysklogd и syslog-ng являются системными службами журналирования. Приложения, использующие «системный журнал», не могут зависеть от одной конкретной программы, например от metalogd, так как остальные программы ничем не хуже. В Portage предусмотрены виртуальные пакеты: каждая служба журналирования описана как провайдер сервиса логгирования в виртуальном пакете logger в категории virtual, поэтому все приложения могут зависеть от пакета virtual/logger. При установке, приложения загрузит первый пакет логгирования, который описан в пакете, если только какой-нибудь из таких пакетов уже не установлен (в случае чего зависимость от виртуального пакета считается удовлетворенной))
12)подключаемые деревья портов(т.н. overlays, дополняющие или перекрывающие основное дерево)
13)всякая приятная мелочёвка, типа внятного setup flow(например, как тут http://devmanual.gentoo.org/ebuild-writing/functions/index.html). Т.е. вам пакетный менеджер предоставляет API с набором функций-заглушек. Вы их переопределяете и рассказываете пакетному менеджеру чего вам надо для установки. И если кто-то плохой поправит мейкфайл, добавив туда аналог rm -rf / это приведёт только к проблемам в песочнице, а не во всей системе.
