Приоритеты оверлеев
acheron 21 апреля, 2009 - 14:35
В каком порядке читаются файлы /etc/make.conf и /usr/portage/local/layman/make.conf ? Например, который окажется в списке первым в данном случае:
$ grep PORTDIR_OVERLAY /usr/portage/local/layman/make.conf PORTDIR_OVERLAY="/usr/portage/local/layman/sabayon $PORTDIR_OVERLAY" $ grep PORTDIR_OVERLAY /etc/make.conf PORTDIR_OVERLAY="/usr/local/portage $PORTDIR_OVERLAY"
Можно ли создать оверлей с приоритетом ниже, чем в основном дереве? То есть чтобы ебилды из него использовались только если в основном дереве нет ничего.
»
- Для комментирования войдите или зарегистрируйтесь
Portage не умеет рулить
Portage не умеет рулить приоритетами оверлеев.
Умеет Paludis
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Насколько им сейчас можно
Насколько им сейчас можно стало пользоваться? Можно ли поставить его и забыть про portage, или придётся время от времени возвращаться?
Без понятия
Без понятия
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
.
Ты попробуй сменить логику рассуждений с "Я хочу!" на "Где оно реально нужно и какие у этой фичи побочные эффекты?
Лично я исходя из второго вопроса склоняюсь к выводу: что может где-то оно и хочется, но даже там не является ни единственным, ни лучшим решением.
Даже в собственно portage хватает мест, над которыми стоит подумать, так зачем забивая на фундамент пытаться что-то городить?
:wq
--
Live free or die
Цитата:"Где оно реально нужно
Пример.
Хочу поставить программу. В официальном дереве её нет. Или нужной версии ещё нет. На скорую руку пишу ебилд, ставлю. Что-нибудь не так, но пользоваться можно.
Через некоторое время нужный ебилд появляется. Почти всегда там учтено что-то, про что я забыл. Если ебилд в каком-нибудь Санрайзе — нормально, у них приоритет стоит выше, чем у оверлея с самописными ебилдами. Автоматически обновляется до правильной конфигурации. Хуже если сразу в основное дерево. Вручную стирать самописный ебилд, а потом, когда он понадобится, долго искать, куда его сохранил, мне менее удобно.
Решение
Даже в случае совпадения версий программы (для случая самописного ебилда и ебилда в основном дереве) есть сомнения в точном совпадении имён.
Но даже если они совпадают до символа, то вместо удаления можно ограничиться переименованием, остальное сделает механизм маскирования (для правильно написанного ебилда).
Если же он в основном дереве появится сразу как unmasked, то проблемы вообще нет: надо лишь грохнуть строку в
package.keywords.:wq
--
Live free or die
Не понял
"Правильно" — это как?
И тогда предложит даунгрейдиться. На последнюю версию без тильды.
.
Как минимум с маской по своей архитектуре.
Так вам шашечки (самописный ебилд в локальном оверлее) или ехать (незамаскированный ебилд в основном дереве)?
Обработка же замаскированных пакетов (особенно если не размаскировывать в принципе, что может привести к сюрпризам, а по конкретным версиям) формализуется не лучшим образом и полной автоматизации не поддаётся.
Причём механизм обработки подобных исключений от числа оверлеев (разумного!) не то, чтобы сильно зависит.
:wq
--
Live free or die
:)
См.выше :) Автоматический переход с локального на основной, когда появится в основном. Без ручного удаления ебилдов, правки каждый раз package.use и package.mask и удаления большей части оверлеев.
И может хватит писать "это не нужно" вместо "я не знаю как"? :)
/
Требование практически невозможного.
1. Удаление ебилдов не нужно.
2. Править package.use (и /make.conf) периодически приходится и когда сидишь на одной ветке в её стабильном ипостаси.
3. Не package.mask, а package.keywords.
Тут в соседней теме (почитай, познавательно) пролетали жалобы на результаты подобной "автоматизации".
Тов. alexxy хорошо ответил:
Вывод простой: полная автоматизация данного действия всё равно невозможна.
:wq
--
Live free or die
:)
«А ещё можно яйца дверью прищемить и жаловаться на неправильные двери.» :) В хендбуках написано ж, не разрешать ~arch для всего сразу.
Кстати, неоднократно видел рассказы как glibc успешно даунгрейдили, в том числе и описанными там способами. Не пробовал.
Не понял вопроса, но торопишься ответить? :) Зачем полная?
emerge -aDNuv worldпозволяет контролировать процесс. Просто надоело каждый раз его прерывать и что-то исправлять..
Только мне кажется, что тов. alexxy писал не про "разрешение ~arch для всего сразу"?..
Бомбу с взведённым ["неизвлекаемым"] взрывателем тоже можно обезвредить...
Это ты несомненно про себя? :)
Приведённая команда к рулению использования замаскированных пакетов не относится никаким боком.
+ к тому я считаю её неправильной и имею на то достаточно веские основания.
:wq
--
Live free or die
:þ
Да. Или напиши как в make.conf прописать ~x86 только для одного пакета. Максимально простым способом, который бы мог получиться случайно :)
И это был не alexxy.
Именно. Эвакуацией, подрывом и повторной постройкой здания из обломков :)
Но мне в своё время помогло подождать, пока ту версию glibc объявили стабильной.
Запускаешь, читаешь, куда автопилот вырулил. Нравится — y, не нравится — n и рули вручную.
Можно подробнее? Что результаты --pretend отличаются от полноценного прогона — сталкивался, но с --ask проблем пока не было. Или ты против интерактивности?
Не совсем верно =) портаж
Не совсем верно =)
портаж начиная с 2.2_rc29 тоже умеет. http://blogs.gentoo.org/zmedico/2009/04/20/overlay_layout_conf
___________________________________________
Working on Gentoo for iPAQ hx4700 and Openmoko Neo Freerunner :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Это гут. Странно только, что
Это гут.
Странно только, что в двадцать девятом(!) RC клепают новые штучки-дрючки
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Спасибо. Буду знать.
Спасибо. Буду знать.
ИМХО, это чревато сюрпрайзами! ;)
Особенно, при безконтрольном обновлении мира. Насколько я понимаю, оверлей нужно иметь один единственный и свой собственный! =)))
А в него сливать необходимое, симлинки кстати рулят. ;) Контроллировать каждый пакет при очередном обновлении придётся всё-равно. Впрочем, нововведение с приоритетами решает, прежде всего, проблему конфликтов ебилдов в разных оверлеях.
По первому вопросу - сперва
По первому вопросу - сперва make.conf, ибо оттуда есть source на конфиг layman-а.
Спасибо.
Спасибо. А где-то ещё может быть? Или на них все должны быть source в /etc/make.conf и /usr/portage/local/layman/make.conf ?
.
Тороплюсь сказать, пока evadim не заламинировал тему по причине участия в ней Anarchist-а,
что мне, например, было бы удобно, чтобы относительно дерева /usr/local/portage имел бОльший приоритет, а остальные оверлеи - мЕньший. Но если бы имелась возможность приоритетами рулить - было бы совсем хорошо.
Так что ИМХО эта тема могла бы вылиться автором в "Portage feature request".
Это подпись, которую невозможно истолковать неправильно
...
темы я ламинирую когда они во флуд перетекают, а Анархист это очень умело делает.
см выше коментарий Alexxy - уже реализовано
Так что ИМХО эта тема могла бы вылиться
У меня возникло ощущение, что наиболее прогрессивные возможности того же Paludis-а понемногу переносят в Portage 2.2, и возможность управления хранилищами на том же уровне появится в ближайшие месяцы.