Правильная организация USE флагов

Не знаю зачем тебе скрипт со списком пакетов, если можно создать сеты со списком пакетов в подкаталоге sets, а потом выполнить emerge @имя_сета.

А use флаги действительно удобнее держать в файлах для каждого пакета отдельно. Можно ещё пытаться прописывать use зависимостей в файл основного пакета, при этом разве может возникнуть ситуация, что один пакет прописан в двух и больше местах, но обычно это не так критично.

У меня, например, есть сеты system-utils (mc, nano, grub, утилиты фс ...), portage-utils (eix, gentoolkit ...), desktop-env (xorg-server, plasma, sddm, dolphin, шрифты и прочее), desktop-apps (браузеры, игры, и прочие прикладные программы).

Если для зависимостей держать отдельный use файл, то можно добавлять комментарий, какой пакет это потребовал.

Не знаю зачем тебе скрипт со списком пакетов, если можно создать сеты со списком пакетов

Спасибо! Из документации не совсем понятно, как с ними обращаться. Допустим, я хочу полностью установить, а потом полностью удалить данный сет. Это будет так:

# emerge --ask @x11-progs
# emerge --deselect @x11-progs
# emerge --ask --depclean

Если никакой пакет из сета x11-progs не тянется по зависимостям больше никем, то да - так правильно. По крайней мере все ненужные более никому пакеты из сета x11-progs будут удалены

Спасибо! В документации есть оговорка для emerge --ask @...:

Selecting "Yes" here will add the set to the
/var/lib/portage/world_sets file.
Use --oneshot to avoid this.

Затем же зачем вообще использовать --oneshot - если хочешь поставить пакет на посмотреть и при следующей чистке планируешь удалить.

Уже установленный пакет можно внести в world-файл с помощью emerge --noreplace. Не уверен правда что это сработает с сетом и world_sets - я просто не пробовал :-)

Use --oneshot to avoid this.
Зачем избегать добавления world_sets? Что в этом такого?

Например, если нужно пересобрать какой-то пакет, который есть в зависимостях, но непосредственно в word не нужен.

Далее предупреждают:

Do not use the --depclean or --unmerge options
to remove the set itself. Doing so may remove
critical packages.

Проверяем. Удаляю небольшой сет, состоящий из 4-х пакетов, с помощью --unmerge, и эти 4 пакета прекрасненько удаляются. Далее оказалось, что один из этих пакетов был нужен в системе. И поэтому, кода я сделал:

emerge --update --deep --with-bdeps=y --newuse @world

Вопрос: почему тогда при удалении сета могут быть прихвачены «critical packages»? Ну наверное же никто не будет включать в сет компилятор, make и прочее.

Как вы следите за порядком с USE флагами?

Для начала я не создаю беспорядка. А уж как только наступает пора навести порядок то навожу его при помощи app-portage/portconf от megabaks.

Или вот еще пример: app-text/xmlto text указано в 2-х файлах в директории /etc/portage/package.use, поскольку это потребовалось для разных пакетов.

Что? Всё, что указано в /etc/portage/package.use применяется сразу при вызове emerge, нет нужны создавать ещё файлы, если в одном из файлов уже указано, что app-text/xmlto нужно собирать с флагом text, то ещё одного файла с определением этого флага для этого пакета создавать не надо. С другой стороны если в каком-нибудь другом файле будет указано, что этот флаг для этого пакета нужно будет выключить, то в зависимости от порядка сортировки по имени файла будет задействована настройка из последнего файла.

Удачи.

Да, ещё всякие package use и unmask мне удобно дописывать из mcedit. В нём по alt+u вызывается оболочка вставляющая результат выполнения команды, в данном случае меня интересует команда eix -c# фрагмент_имени_пакета.

Её выполнение вставит всё что найдётся по запросу в формате категория/имя_пакета. При следующем вызове alt+u нужно будет изменить только фрагмент имени пакета, так как будет отображена предыдущая команда

в зависимости от порядка сортировки по имени файла будет задействована настройка из последнего файла.

Этот самый «порядок сортировки» как-то задокументирован? Или зависит от погоды на Европе, спутнике планеты Юпитер, что на данный момент более случайная величина, чем погода в Европе, части континента Евразии на планете Земля?
«Случаный порядок» - интересный, однако, термин.

Как выводится в ls так и будет обработано, просто по алфавиту.

Как выводится в ls так и будет обработано, просто по алфавиту.

Во-первых, пруф, что также как ls.
Во-вторых, допустим как ls, а ls (который в coreutils) сортирует в засимости от установленной локали, а у меня русские файлы или даже с непечатными символами, а локаль - испанский koi8r (допустим, такое может быть на спутнике Юпитера). Что мне насортирует ls?

Зачем тебе в именах файлов в package.use использовать кириллицу или другие национальные символы, тем более непечатные символы?

Если там только символы английского алфавита и цифры, то файлы обходятся согласно алфавитному порядку.

Не надо лезть в бутылку, искать где это расписано мне лень, я знаю как это работает в случае описанных условий в этом сообщении.

Если тебя это интересует более детально найди сам и можешь даже поделиться ссылкой.

Удачи.

Одним файлом удобнее, насколько шизанутым нужно быть, чтобы оправдывать ворох файлов это пипец просто.

Зачем тебе в именах файлов ... национальные символы ... ?
Если там только символы английского алфавита ...
... это работает в случае описанных условий в этом сообщении.

Как только докажешь, что английский - это не национальный, а единственно-верный общевселенский алфавит, то можно согласится с тобой.
Но я люблю (любил) ставить для перед важными файлами символы "!", «_» (воскл. знак и подчеркивание), и, прикинь, эти файлы сортируются по разному в завсимости от LANG=«C» или LANG=«en_US.utf8». По мне эти символы вполне безобидные, но результат адски хаотичный.

Мне незачем тебе или кому-либо что-то доказывать.

Я описал особенность поведения и изложил условия при которых всё работает корректно и мне это приемлемо и устраивает, если ты действуешь как-то по другому - разбирайся сам.

Удачи.

Ну так, ты сперва приведи общевселенский алфавит, который не зависит от локали. Вдруг у меня локаль, где латинские буквы и цифры отсортированы в обратном или хаотичном порядке (назовем эту локаль «en_EU.jupiter»), и вся сортировка не-национальных-английских слов будет соотвествующая.

У меня, например, есть сеты

Так получилось, что поскольку о сетах я узнал не сразу, то часть входящих в эти сеты пакетов было установлено ранее. Вот, например, genkernel был установлен командой emerge genkernel. Теперь же он входит в сет @mysystempkg. Далее я сделал:

emerge @mysystempkg

Допустим, вышла новая версия genkernel. Как теперь правильно обновляться:

emerge --update ... @world

emerge --update ... @mysystempkg

Если хочется обновить только genkernel, то я бы обновился так: emerge -1avq genkernel

Это будет быстрее, т.к. не будут рассчитываться зависимости для других пакетов сетов. А если нет желания обновить отдельно сет, то в других случаях лучше сразу обновить @world. Когда-то давно я сначала обновлял system, а потом world, но сейчас это часто затруднительно из-за вываливающихся блокировок, которые отсутствуют или разрешаются автоматически, если сразу сказать обновить @world.

Do not use the --depclean...to remove the set itself

Это странно - скорее всего некорректно считается дерево зависимостей для сета. Или(что вероятнее) - они считаются частью world и поэтому --depclean НИЧЕГО из состава сета не удалит.

Удаляю небольшой сет, состоящий из 4-х пакетов, с помощью --unmerge

Это как раз объяснимо - в отличие от --depclean, --unmerge не смотрит на зависимости, а тупо выкашивает пакеты. Поэтому если ты так попросишь удалить какой-нибудь сет @cool-desktop-environment, куда кто-нибудь включит, например, gtk, то тебя ждет^W уже не ждет неприятный сюрприз :-)

Так что алгоритм тут скорее всего таков:

1) удаляем сет из world_sets;
2) запускаем --depclean;