>>Опция, отвечающая за pulseaudio всегда для всех пакетов
>>называется pulseaudio и никак иначе.
> Примеры так навскидку не назову, но не для всех опций есть стандартизация. В этих случаях "стандартизация" не нужна. Конечно, есть опции, специфичные
для одного конкретного пакета.
>>Здесь проблема. К зависимостям нельзя установить требования по требуемым options.
> А и не надо. Надо, чтобы можно было удобно посмотреть, что требуется
> включить/выключить, потом посмотреть ишшо раз на результат, при надобности повторить и
> так до полного удовлетворения.
Пф, тривиальный скрипт на несколько десятков строк на шеле.
Я даже не буду их приводить. В pkgsrc информация о том, с какими
опциями установленный пакет собран регистрируется в pkgdb (PKG_OPTIONS).
В отличие, если не ошибаюсь, от фряшных портов, rpm и dpkg.
Другое дело, что в pkgsrc необходимые "хотелки" к опциям зависимостей
даже нигде не регистрируются. Честно говоря, мне трудно оценить объем
работы, необходимый для этого. На практике и в самом деле достаточно
пересобрать нужный пакет-зависимость, если сборка сломалась и не мучиться.
Или робота построить. Все решает отношение цена/выхлоп. Есть и более важные
места, куда нужно приложить силы.
>>Это в pkgsrc решено 1000 лет назад. Двумя способами: pbulk, distbb.
> В генте distcc и ccache, насчет pbulk - не помню.
distcc -- довольно слабый вариант распараллеливания.
Не параллелятся configure, cmake, scons и т.д., порой занимающие
львиную долю времени сборки.
pbulk и distbb параллелят/дистрибутят все этапы сборки.
Иногда это надо и очень удобно.
ccache вообще из другой оперы. Но поддержка и distcc и ccache,
естественно, в pkgsrc есть издревле.
>>Не понял. Это зачем?
> Зачем вообще контрольные суммы? Для секурности же! :)
Э-э-эм. Как бы это сказать по-мягче.
Контрольные суммы нужны для distfiles
и скачиваемых патчей. И все. Остальное скачивается
из источника, которому можно доверять.
>>4 питона, 3 руби, 2 пыхпыха, много апачей со всеми модулями.
> Варивны перечисленного.
Чего?
> ФишкА в том, что в pkgsrc это _отдельные_ пакеты, а в portage
> - разные версии _одного_ пакета. Почувствуй разницу.
В pkgsrc модули для подобных вещей -- это тоже варианты ОДНОГО пакеты.
> Это как если бы lang/gcc47 апдейтнулся с 4.7.1 до 4.7.2,
> ты не можешь установить то
> и другое вместе, а в генте - сможешь. Не для всех
> пакетов слоты есть, но для (почти) всех, для которых это имеет
> смысл - есть.
В pkgsrc есть аналогичная штука, pkg_views. Опять же "не для всех пакетов
слоты есть, но для тех...". В общем, я этой хреновиной никогда
не пользовался, не вижу необходимости.
Думаю, самое время достать шашки (NixOS).
Но мне достаточно возможности забутстрапить pkgsrc в другое место
и там иметь дубликаты чего угодно.
>>hardened штука отличная, наслышан, но это уже скорее уровня дистрибутива.
> Это профиль portage.
Я к тому, что hardened профиль затрагивает всю систему,
включая патчи на ядро. PaX, hardened chroot и вся эта компания.
>>В терминологии pkgsrc это meta package.
> Не, meta-pkgs/ - это другое. meta-pkgs/kde4 - это просто все kde оптом,
> в генте это kde-base/kde-meta, вот это тоже самое. А аналога virtual/cron
> virtual/pager - нету,
Есть. Вношу поправку. В pkgsrc есть альтернативные зависимости,
типа "зависит от пакета A или от пакета B".
meta package + alternative dependencies = virtual package.
Хотя как отдельное понятие оно нигде не фигурирует.
>>Он неверное, не знает про wip.:)
Это откуда здесь взялось?
