имеет настраиваемые опции для пакетов, по аналогии с USE-флагами в portage, но не компилирует исходники с чистого листа, а компонует скачиваемые с репозитария объектные файлы; перекомпилирует только отдельные модули, если это необходимо.
Примечание:
@@А смысл? От держания репозитория готовых бинарников ну ничем не отличается, только сложностями с разными ABI разных версий компилятора.@@
1. уменьшается время сборки, т.к. в том же portage при хорошем интернет-соединении основная часть времени уходит именно на компиляцию.
2. в нормальных условиях, хранение объектных файлов пакетов, скомпилированных с разными USE, займет меньше места: во-первых, большинство флагов влияет не на все модули пакета, а только на некоторые. Во-вторых, хранение нескольких вариантов бинарных пакетов (с разным набором функций) однозначно тяжелее, чем только объектников.
3. configure-скрипты выполнять не потребуется. Это также экономит время сборки, поскольку тесты, которые там проводятся, повторяются почти в каждом пакете снова и снова (config.cache помогает только на переконфигурировании) Для проверки наличия библиотек, программ, заголовков можно перечислить их в ebuild-файле. Директории, префикс и прочие константы можно заменять в реальном времени перед сборкой, через регэкспы, diff/patch, и просто редактируя obj-файлы.
4. быстрый патчинг и обновления. Чтобы пропатчить программу, надо всего-лишь скачать требуемую часть исходников (уже сконфигурированную под выбранные arch/compiler, ключи --with, --enable), пропатчить нужные файлы, скомпилировать и слинковать. После чего, и скачанные исходники и obj'ы могут быть спокойно удалены с диска за ненадобностью.
для совместимости с различными компиляторами и архитектурами, объектные файлы можно раскидывать по разным каталогам, например вида:
/distfiles/ARCH/COMPILER-VERSION/ ( для i686, gcc 4.3.3 будет /distfiles/i686/gcc-4.3.3 ). Чтобы уменьшить занимаемое пространство, можно потребовать определенную версию компилятора для каждой архитектуры, например gcc-current и gcc-stable. Получаем, что единственный пакет, для которого в обязательном порядке следует создать субдиректории для всевозможных компиляторов, это gcc.
Бинарные репозитарии, конечно, просты в реализации и использовании, но если рассмотреть пакет openoffice-bin на примере трех флагов: gnome, kde, java, из которых 2 взаимоисключающих, получаем два-факториал вариантов образа пакета. Если независимых флагов, скажем, 9, то размер на такое хранилище потребуется немалый (факториал растет быстро).
В целом, вопрос удобства для пользователя в установке пакета и экономии места на зеркалах. Минимум требуемого места - максимум mirror'ов.
Примечание:
Ramn, спасибо за поправку
RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.
Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.
Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.