Про бинарные пакеты [1/3 SOLVED]
Волею судьбы являюсь большим поклонником маленьких ноутбуков, ибо удобно для работы. Друзъя дебианщики все время подкалывали меня на тему, что уж очень долго надо генту обновлять, да еще девелоперские пакеты ставить, да потом все компилить, типа у нас просто apt-get update && apt-get upgrade и система как новая и даже можно без хедеров ибо не нужны, а типа держать на сервере gcc вообще вселенское зло. На что я им постянно объяснял, что зато уж у меня система допиленная под мой камень и с моими потребностями в зависимостях. И вот, приобретя свой новый субноут, я поставил себе цель получить гибкость генту в системе с бинарными пакетами, а на ноуте не собирать ни одного пакета. Для чего на отдельном сервере был заведен чрут и система для ноутбука собиралась вся в нем, после чего на ноуте выполнялось что-то типа emerge world -euDNGKv и пакеты с сервера благополучно ставились на ноут.
Так вот, я обратил внимание, что в ебилдах майнтейнеры очень часто применяют выражения типа RDEPEND="${DEPEND}" или вообще упоминания о RDEPEND не встречается. В результате система, стоящая на ноуте, очень мало отличается от системы, которая в чруте на сервере. Очень много ненужных пакетов ставится, необходимых только для компиляции, но уж никак не для работы. Нет, мне конечно же не сложно прошерстить все установленные у меня пакеты, необходимые скинуть в оверлей и поправить у них RDEPEND и в дальнейшем весь этот оверлей поддерживать в одно лицо или тоже самое делать с package.provided :) Просто зачем мне на ноуте все версии automake и autoconf, gcc, сырцы ядра, куча хедеров от иксов и еще дофига всево, что просто никогда не будет использоваться?
В некоторых пакетах идет проверка на наличие каких либо опций в исходниках ядра, поэтому без сырцов и их бинарные версии развернуть проблемно, но это я обошел, создав на ноуте минимальный набор файлов из ядра, который требуется для установки пакетов, а ядро так же собирается на сервере в чруте, потом в готовом виде кочует на ноут.
Далее остается проблема с хедерами внутри скомпиленного пакета. Они мне не нужны на ноуте, но избавиться от них средствами портежей невозможно.
Итак, подведем итог:
1. Проблема RDEPEND="${DEPEND}" при установке системы из скомпиленных пакетов. Очень много лишнего ставится.
2. Зависимость некоторых пакетов от наличия исходников ядра. Решение есть, но некошерное.
3. Невозможность выкинуть из скомпиленного пакета хедеры. Тут вообще засада.
Хотелось бы услышать ваше мнение по этим трем проблемам.
- Для комментирования войдите или зарегистрируйтесь
Мож стоит
Мож стоит отказатся от генты и поставить тот-же debian, или можно freebsd, archlinux у них тоже есть порты и можно собирать пакеты из исходников со своими зависемостями...
Не могу
Не могу я от нее отказаться, ибо привык сильно и комфортно мне в ней, за исключением вышеозначеных проблем.
Тогда что могу
Тогда что могу предложить:
Можно попробовать сделать пустые ебилды тех программ которые тебе на ноуте не нужны...
Или более правельно указать что они присутствуют в системе указав это в каком-то файле в каталоге /etc/portage/ (в документации точнее сказано)...
Точнее я об
Точнее я об этом уже писал, это файл /etc/portage/profile/package.provided
Но сложность заключается в том, что в этом файле должны быть указаны не только имена пакетов, но и версии, например
dev-lang/yasm-0.5.0
И что же при каждом обновлении системы мне придется следить, а не обновилась ли версия пакета, котороый я не желаю видеть в системе на ноуте, но который нужен на системе в чруте сервера?
А если таких пакетов наберется сотня? Аналогичную проблему имеем с фиктивными ебилдами...
Поэтому, на мой взгляд, надо как-то сообщать майнтейнеру пакета, что в общем-то все что написано в DEPEND не всегда нужно в RDEPEND, тогда проблема отпадет сама собой.
echo
и больше не обновляется
Аха, и если оно
Аха, и если оно по зависимостям необходимо, то портежи все изругаются и ничего ставить не будут. Не стоит задача заморозить пакет, стоит задача его не ставить, там где он не нужен.
Частичное решение
Более внимательное изучение портежей показало наличие замечательной переменной INSTALL_MASK, благодаря которой проблема с хедерами внутри бинарных пакетов была успешно решена.
В make.conf на ноуте было прописано
INSTALL_MASK="*/include/ *.h *.a"
и при установке бинарного пакета хедеры больше не ставяться.
Так что третья вышеописанная проблема исключается.
И вечно ты, Котофеич, странного хочешь.
Блин, Генту, на то и генту, что бы иметь все хедеры на месте, а не вспоминать потом какой dev-пакет не поставил.
Вообще я конечно покурю внимательно доки, а в крайнем случае надо будет на gentoo.org на форумах спросить, на английском форуме конечно :)
__
"Я нолдо, я рожден в Эндорэ.
Я кано, мой Король -- Гил-Галад"
Так в том и
Так в том и идея, что dev-пакеты не нужны. Не используются они на ноуте. Вот в чруте на сервере - да, там полный набор. Так что и вспоминать не придется.
Я может ещё и не
Я может ещё и не разобрался, но в чём проблема грохнуть все пакеты со словом dev в заголовке?
Смотри, ты что спрашиваешь: "Если разрабы пакета не указали, какие зависимости более не нужны, и сам я не хочу их искать, то как я получу их указанными?" Не находишь, что никак?
Вариант только - грохни все dev пакеты, кроме gcc, сделай revdep-rebuild (Кстати, я в него не верю!) и грохни сам gcc. И это я наугад сказал.
Внимательнее
Внимательнее читайте пожалуйста первый пост. Мне не проблема найти какие пакеты нужны а какие нет. Проблема в том, что я не хочу поддерживать список этих пакетов в /etc/portage/profile/package.provided или каким либо другим способом, потому что портежи имеют механизм, благодаря которому такой ситуации можно избежать. Просто майнтейнеры пакетов им не пользуются, а в большинстве случаев ограничиваются банальным RDEPEND="${DEPEND}". Далее, о каком revdep-rebuild может идти речь на системе, где не было собрано ни одного пакета? Далее, если я грохну все dev пакеты на ноуте, то уж не притащатся ли они при следующем emerge world -uDNGKv ? Какое-то противоречие получается.
А теперь представим, что на основе генту я собираю некую embedded систему под мелкую железку. И что же мне теперь в железку и gcc и прочие девелоперские пакеты зашивать?
нууу...
Я может совсем извращенец)))
Но собирал бы бинарники на сервере под свой субноут, со всеми оптимизациями гцц. И ядро соответственно.
Сделал собственный локальный бинарный оверлей и ставил с него.
А так как пользователей субноутов великое множество, то можно и поделиться))
P.S. вообще бинарники оптимизированные под конкретную платформу это очень вкусно)
И если будет поддержка ноутов, субноутов, арм платформ от самих мейнтейнеров со своим оверлеем, то выбор дистрибутива просто очевиден)