 |
|
|
|
Знакомимся с Gentoo. Часть II: базовые настройки и работа с Portage
Знакомимся с Gentoo Часть II: базовые настройки и работа с Portage В вопросах установки Gentoo не сильно-то заботится о пользователе, вынуждая его осознанно принимать каждое решение. А как дела обстоят с настройкой и сопровождением системы? И здесь у Gentoo есть свои особенности. В первой части статьи мы занимались вопросами установки Gentoo. Задача нетривиальная, но весьма интересная. Продолжим знакомство с этим дистрибутивом, сегодня на повестке дня вопросы настройки Gentoo и основы работы с системой Portage. В какое время мы живём? Вопрос, скорее, философский, но если его сузить до вопроса выбора часового пояса, то делается это традиционно: # cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime В некоторых руководствах можно встретить рекомендацию вместо копирования создавать символьную ссылку. Если у вас каталог /usr расположен на корневом разделе, то можно поступить и так. Если же /usr вынесен на отдельный раздел, то лучше явно скопировать информацию о зоне, чтобы система корректно работала и в случае, когда будет смонтирована только корневая файловая система. А как всё это загружается? Теперь рассмотрим сценарии инициализации системы. В принципе всё достаточно традиционно для Linux (на то он и Linux), то есть управление запуском выполняется на уровне абстракции, именуемой runlevel. Наиболее часто это переводят как «уровни исполнения», будем и мы придерживаться этого термина. Если говорить упрощённо, то уровень исполнения определяет набор сервисов, которые должны быть запущены или остановлены при переходе на тот или иной уровень. Управление сервисами выполняется с помощью сценариев инициализации. В большинстве дистрибутивов Linux принята следующая схема: в каталоге /etc/init.d размещаются сценарии управления различными службами, а в каталогах rcN.d, где N – номер уровня runlevel, создаются символьные ссылки на соответствующие сценарии. Конкретное местоположение каталогов rcN.d зависит от дистрибутива. Мне встречались следующие размещения:
Для именования ссылок принимается специальный формат: <действие><порядок><имя> где:
Например, ссылка S15cron в каталоге rc2.d означает, что при переходе на runlevel 2 должен запускаться (буква «S») сервис cron. В Gentoo всё реализовано несколько иначе. Каталог /etc/init.d также присутствует и для тех же целей. Но вот запуск сценариев и их формат заметно отличаются. Во-первых, каталоги уровней запуска размещаются в /etc/runlevels и имеют более «функциональные» имена: boot, default, single, nonetwork. Причём эти имена связаны с конкретным уровнем исполнения лишь в файле /etc/inittab, так что вы, при желании, можете переопределить их имена, создать свои уровни и т. д. Единственный каталог, который не рекомендуется переименовывать – это boot, отвечающий за запуск программ на этапе первоначальной загрузки системы. Во-вторых, отличается формат самих сценариев инициализации. Если вы уже заглянули в один из указанных выше каталогов, то заметили, что ссылки здесь называются просто по имени сервиса. А как же тогда управлять порядком их исполнения? Для этого существует механизм расчёта порядка запуска на основании зависимостей. Если вы просмотрите какой-нибудь из init-сценариев, то заметите, что в нём определён ряд подпрограмм. Обязательной является подпрограмма start(), отвечающая за запуск сервиса. Зачастую определены также stop(), checkconfig() и т. д. Названия говорят сами за себя. Упомянутые выше зависимости определяются в подпрограмме depend(). Так вот, в depend() перечисляются службы, от которых зависит данный сервис. Выделяют два типа зависимостей – need (обязательная) и use (дополнительная). Программа просто не запустится, если не будет запущена служба, указанная в строке need. В случае use-зависимости программа может работать и без соответствующих сервисов, но если они в системе присутствуют, то должны быть запущены первыми. Если между сервисами нет отношения зависимости, но требуется явно указать порядок их запуска, можно в depend() использовать строки before и after. А что делать, если программа нуждается не в конкретной программе, а просто в сервисе, который может предоставляться одной из нескольких программ? Например, некоторые приложения будут зависеть от службы журналирования системной информации (syslog), однако реализована она может быть несколькими программами на выбор администратора. В Gentoo данная проблема решается с помощью так называемых виртуальных сервисов, которые описываются в depend() в строке provide. Например, как syslogng, так и sysklogd при установке зарегистрируют себя как сервис logger, и тогда для других зависимых приложений достаточно будет указать «need logger». В качестве примера рассмотрим фрагмент файла /etc/init.d/vixie-cron: depend() { use clock logger need localmount provide cron } Здесь вы видите, что этот сервис регистрирует себя в качестве виртуального сервиса «cron», обязательно требует, чтобы были смонтированы локальные файловые системы(?) и хотел бы, чтобы сервис clock и виртуальный сервис logger были запущены до него (если они вообще есть в системе). На основании сведений, содержащихся в depend(), и рассчитывается порядок запуска сервисов. Кстати, установив переменную RC_PARALLEL_STARTUP в файле /etc/conf.d/rc в значение «yes», можно позволить системе параллельно запускать сценарии инициализации, не зависящие друг от друга (на том же принципе основана работа initng). Для управления сервисами служит утилита rcupdate. Мы уже сталкивались с ней в первой части статьи, когда регистрировали в системе нужные нам утилиты vixiecron и syslogng. Её синтаксис следующий: rc-update <действие> [<программа>] <уровень> где:
Работа программы заключается в размещении (или удалении) символьной ссылки на сценарий инициализации в каталоге соответствующего уровня исполнения. Кроме того, при её запуске рассчитывается кэш зависимостей (по умолчанию соответствующие файлы расположены в /var/lib/init.d/, что определяется переменной svcdir в /etc/conf.d/rc), который и используется при загрузке системы. Что бы тут ещё поменять? Некоторые глобальные настройки (например, редактор по умолчанию и DISPLAYMANAGER) можно установить в файле /etc/rc.conf. Он, конечно, играет в системе не такую решающую роль, как во FreeBSD, но забывать о нём не нужно. Каталог /etc/env.d служит для установки значений различных переменных окружения. Для этого используется несколько файлов, которые обрабатываются в лексикографическом порядке. Если одна и та же переменная задаётся в нескольких файлах, силу будет иметь то значение, которое будет присвоено последним. Также нужно упомянуть следующую команду: # env-update Она обрабатывает файлы каталога env.d и создаёт результирующий файл /etc/profile.env, который затем используется сценарием /etc/profile (только не поддавайтесь соблазну изменять переменные окружения непосредственно в нём). Файл /etc/profile управляет настройками среды окружения. Помимо обработки упомянутого ранее файла profile.env, здесь устанавливаются: переменная PATH, значение umask, приглашение командной строки (PS1), редактор по умолчанию (переменная EDITOR), которая берётся из файла /etc/rc.conf, но в принципе ничто не мешает задать её непосредственно в profile. Основные же настройки сосредоточены в каталоге /etc/conf.d. Здесь вы найдёте конфигурационные файлы для задания системного времени (clock) – не забудьте указать здесь «local» вместо «UTC», имени хоста (hostname), настройки sshd, сети (файл net) и т. д. Ещё один достаточно важный для системы файл, размещающийся в этом каталоге – rc. Здесь описаны переменные, влияющие на инициализацию. Также нужно упомянуть про каталог /etc/modules.autoload.d. Здесь, в файле, соответствующем вашему ядру, вы можете явно указать загрузку нужных для работы системы модулей, например, драйверов сетевых карт. Также загляните в каталог /etc/modules.d, где размещается ещё несколько конфигурационных файлов, касающихся модулей ядра. Чуть подробнее о сети Поскольку возможность работать в сети в наши дни вполне можно считать жизненно необходимой, то подробнее остановимся на сетевых настройках. Как уже упоминалось, настройки сети можно найти в файле /etc/conf.d/net. Это несколько отличается от общепринятого способа. Например, в SUSE сценарий init.d/network, запускаясь на соответствующем уровне, ищет параметры конфигурации в файлах каталога /etc/sysconfig/network. Здесь же все настройки сосредоточены в одном файле – net. Скорее всего, при первой установке он будет пуст, но зато рядом должен быть файл net.example, где приведены примеры наиболее типичных настроек. Внимательно ознакомьтесь с ним и наберите нужные строки в файле net. Например, настройка на статические адреса может выглядеть следующим образом: config_eth1=("10.0.0.103/24") routes_eth1=("default gw 10.0.0.254") При необходимости присвоить одной сетевой карте несколько IP-адресов (используя механизм alias) или задать адреса IPv6, можно их перечислить таким образом: #config_eth0=( # "192.168.0.2/24" # "4321:0:1:2:3:4:567:89ac" #) Но этого ещё недостаточно. Нужно обеспечить автоматический запуск сети при загрузке. Если у вас только один адаптер – eth0, то для его запуска уже должен быть сценарий инициализации net.eth0 в каталоге /etc/init.d (он является ссылкой на net.lo, размещённый в этом же каталоге). Для других устройств (например, eth1) нужно создать свои ссылки с именем, соответствующим шаблону «net.<устройство>». Ну и с помощью rc-update обеспечить автоматический запуск скрипта при инициализации соответствующего уровня исполнения. А если мне нужно больше? Очевидно, что возможностей, заложенных в базовую систему, будет недостаточно для полноценной работы. Рано или поздно (а если говорить о Gentoo, то буквально с первых минут работы) вам понадобится установить ту или иную программу. В Gentoo для этих целей реализована близкая по духу к коллекции портов FreeBSD система Portage. В первой части статьи уже приводились примеры её использования, когда устанавливались исходные коды ядра, утилита vixiecron и т. д. Настало время обсудить возможности Portage более подробно. Основное отличие Portage от портов BSD заключается в том, что в Gentoo не стали ограничиваться управлением только сторонними программами – с помощью Portage вы можете собирать/обновлять и базовые компоненты. Кроме того, разработчики Portage решили управлять сборкой не с помощью традиционных файлов Makefile, а используя специальные ebuild-скрипты (если заглянуть в один из них, то будет видно, что он служит для тех же задач – описывает версии, зависимости, сетевые адреса, где следует искать необходимые файлы, параметры конфигурации и т. д.). И если в той же FreeBSD для комфортной работы с портами нужно устанавливать ряд дополнительных программ (portupgrade, pkg_cutleaves), то Gentoo предоставляет в ваше распоряжение одну мощную высокоуровневую утилиту – emerge, которая обеспечивает доступ практически ко всему функционалу системы Portage. Приведу несколько наиболее полезных примеров использования (подробности – в man emerge): # emerge --search apache # emerge --searchdesc http-server Так выполняется поиск в дереве Portage – первая строка демонстрирует поиск по имени пакета, вторая – по описанию (можно использовать и регулярные выражения). В принципе, дефисы можно и опустить (используя как emerge search mc), но лучше чётко видеть, что является командой, а что – аргументом. # emerge -pv links Ключ -p (--pretend) заставляет emerge вместо реальной работы просто сообщить, какие действия она собирается выполнить; использование -v (--verbose) увеличивает информативность вывода. Помимо всего прочего, в выводе этой команды будет дана информация об общем объёме трафика, который потребуется для закачки всех необходимых пакетов. Настоятельно рекомендую (по крайней мере, первое время) каждую команду emerge предварять такой же, но с ключом -p: это позволит не только «прикинуть» объём закачки, но и убедиться в правильности используемых флагов. Например, если «emerge -pv links» сообщает вам о намерении скачать из Интернета свыше 60 Мб, то, просмотрев список зависимых пакетов (который выводится здесь же), вы быстро обнаружите ненужные вам пакеты X11, qt и т. п. Несколько экспериментов с флагами позволят избежать их установки, отключив флаг sdl: «USE=”sdl” emerge links». # emerge -f iproute2 С помощью ключа -f (--fetchonly) можно только скачать все необходимые для установки файлы. Это может быть полезно, если у вас модемное соединение (в этом случае сначала всё скачивается, а затем можно отключиться от сети и потихоньку всё это собирать). Или, если вам нужно установить пакет на машине, не имеющей выхода в Интернет, но вы не собираетесь ставить его на свой сервер, опять же поможет этот ключ. # emerge --info Данная команда выводит список текущих настроек системы Portage. Наибольший интерес, видимо, будет представлять переменная USE, отображающая установленные по умолчанию значения (о ней мы поговорим чуть позже). # emerge --newuse mc Так, можно пересобрать (при необходимости) установленное приложение с учётом изменений, сделанных в списке флагов USE (без ключа --newuse пересборка выполнится со старыми флагами). # emerge -u gentoo-sources Ключ -u (--update) приводит к переустановке указанного пакета, если в этом есть необходимость (например, появилась новая версия). # emerge --sync Эта команда выполняет обновление дерева Portage до актуального состояния. Рекомендуется обновлять Portage хотя бы раз в неделю. Однако с целью экономии трафика лучше использовать скрипт emerge-delta-webrsync, который устанавливается в систему уже известным способом: # emerge emerge-delta-webrsync Первый запуск emerge-delta-webrsync приведёт к скачиванию достаточно большого объёма информации (порядка 30 Мб), в дальнейшем расход трафика будет небольшим. В качестве параметра можно указывать «общее» имя пакета (например, mc), конкретную версию (app-misc/mc-4.6.0-r14), ограничивать с помощью символов «<», «>» и т. д. верхние и нижние границы версий (по умолчанию будет установлена последняя стабильная версия, хотя бывают и исключения – зависит от майнтейнера конкретного портежа). Полный список возможных для установки пакетов можно посмотреть в соответствующем каталоге дерева Portage, обращая внимание на ebuild-файлы: # cd /usr/portage/app-misc/mc # ls | grep ebuild
Есть также пара так называемых классов – system и world, – позволяющих, например, одним махом обновить всю систему со всеми установленными программами. Первый отвечает за работу с базовой системой (без программ, установленных пользователем), второй – за все пакеты, включая те, которые подпадают под действие system: # emerge -u world Информацию по всем установленным программам можно найти в каталоге /var/db/pkg. Здесь формируется аналогичное дерево подкаталогов по категориям, но помимо общего названия программы указывается и её версия. Например, всю информацию по установленному в системе пакету syslog-ng можно будет найти в /var/db/pkg/app-admin/syslog-ng-1.6.9. Система Portage заслуживает отдельной большой статьи (а то и нескольких), поэтому здесь я просто укажу, на что ещё нужно обратить внимание. Во-первых, существует понятие защищённых каталогов (например, /etc), т.е. таких, где изменения не могут быть выполнены автоматически и требуют вмешательства администратора. Сделано это для того, чтобы не «затереть» при обновлении с такой любовью настроенные конфигурационные файлы. Во-вторых, Portage позволяет управлять одновременно несколькими версиями одной и той же программы. Достигается это за счёт использования так называемых «слотов» (SLOT). В-третьих, некоторые пакеты, в которых обнаружены ошибки или которые недостаточно протестированы, могут «маскироваться». Однако при необходимости такой пакет всё равно можно установить. Подробности можно найти в «Руководстве». Также следует упомянуть об установке бинарных пакетов. Для этого следует задать ключ -k (--usepkg) в команде emerge, чтобы она попыталась сначала найти двоичный пакет, и только в случае неудачи приступала к стандартной инсталляции из исходных кодов. Ключ -K (--usepkgonly) полностью запрещает использование исходников, требуя обязательного использования двоичного пакета. В частности, этим можно воспользоваться для массовой установки какого-то приложения на несколько однотипных систем (собрать двоичный пакет позволяет ключ -b команды emerge). Флажковая азбука Прежде чем говорить о переменной USE, пару слов нужно сказать о зависимостях пакетов. Помимо деления на зависимости сборки (DEPEND) и исполнения (RDEPEND), которые в большинстве случаев совпадают, каждый зависимый пакет является либо обязательным (без которого данное приложение вообще не соберётся или не будет работать), либо вспомогательным (который не требуется собственно для работы приложения, но предоставляет ему дополнительную функциональность). Так вот, вспомогательными зависимостями (которые также называют зависимости использования, по аналогии со сценариями инициализации) можно достаточно гибко управлять. Например, если вы не собираетесь использовать графическую подсистему, то при установке Midnight Commander соответствующую поддержку лучше отключить. Делается это с помощью переменной USE, например, так: # USE=”-X” emerge mc Знак «минус» перед флагом означает, что соответствующие зависимости использовать не нужно. Если требуется принудительно включить поддержку того или иного пакета, укажите его без дополнительных знаков: # USE=”slang” emerge mc Несколько флагов разделяются пробелом: «USE=”-X slang”». Как можно увидеть в выводе команды emerge --info, по умолчанию переменная USE имеет достаточно много значений. Указанная в командной строке, она не переопределяет установленное значение, а вносит соответствующие коррективы. Итоговое значение складывается из следующих значений (в порядке возрастания приоритета): глобальные флаги (из /etc/make.globals); флаги профиля (из /etc/make.profile/make.defaults); флаги из /etc/make.conf; индивидуальные флаги, описанные в /etc/portage/package.use; флаги, установленные в командной строке. Ещё немного про настройки Познакомившись с Portage подробнее, нужно вернуться ненадолго к настройкам системы и рассмотреть параметры, влияющие на работу системы управления программами. Работа Portage определяется так называемыми профилями (profiles), в которых определяются специфические для той или иной платформы настройки. Используется тот профиль, ссылкой на который является файл /etc/make.profile. Если вы выбрали Stage3 для правильной платформы, то нужная ссылка уже будет создана. Если вам необходимо переопределить какие-то параметры, то исправлять их непосредственно в файлах профиля не рекомендуется, поскольку при обновлении дерева Portage все изменения будут потеряны. Для тонкой настройки предназначен каталог /etc/portage. По умолчанию он пуст (либо вообще отсутствует). Здесь вы можете определить следующие файлы:
Есть и другие – читайте документацию. Мы – русские люди Ещё один важный для российских пользователей (да и вообще для всех, чей родной язык – не английский) вопрос – это локализация. В качестве примера рассмотрим использование русской локали и настройку системы на работу с кодировкой UTF-8 как наиболее перспективной (не хочу сказать, что она идеальна, но это, похоже, единственный путь избавиться от разброда с различными «cp», «koi», «iso» и проч.). Но сначала, отдавая дань традициям, рассмотрим настройку koi8-r. Рабочая кодировка в Gentoo настраивается в двух файлах: /etc/conf.d/consolefont, где задаётся используемый в консоли шрифт и (при необходимости) таблица перекодировки, и /etc/conf.d/keymaps, где указываются нужные раскладки. Например, чтобы настроить систему на работу с koi8-r, рекомендуется использовать «CONSOLEFONT=”cp866-8x16”» и «CONSOLETRANSLATION=”koi2alt”» в файле consolefont, а в keymaps добавить следующие строки: KEYMAP=”ru4” SET_WINDOWKEYS=”yes” Первой строкой выбирается раскладка (есть и другие, см. /usr/share/consolefonts/), затем указываем, что следует использовать размещение клавиш (в частности, знаков препинания), принятое в Windows – именно такие метки наносят сейчас практически на все клавиатуры. Последним аккордом будет указание переменной окружения «LANG=”ru_RU.KOI8-R”», что можно сделать либо глобально (например, добавив эту строку в файл /etc/env.d/02locale), либо в настройках конкретных пользователей. Однако мы решили использовать UTF-8. Здесь есть несколько дополнительных моментов. Во-первых, в базовой системе нет консольных шрифтов, соответствующих этой кодировке (по крайней мере, мне их найти не удалось, хотя всё подряд и не перебирал). Так что нужно их поставить, благо делается это достаточно просто: # USE=”-X” emerge terminus-font «Иксы» (X Window) я отключил здесь потому, что пока не планирую их использовать (на самом деле, «-X» у меня прописан глобально, в /etc/make.conf, здесь переменная показана для наглядности). Вы, естественно, можете задать те флаги, которые нужны вам. Во-вторых, в файле /etc/rc.conf необходимо установить переменную UNICODE в значение «yes», чтобы система знала, с чем мы работаем. И, в-третьих, полезно будет задать глобальный флаг «USE=”unicode”», если он ещё не установлен. Далее всё, как и в случае с koi8-r: записываем строку «CONSOLEFONT=”ter-k14n”» в файл /etc/conf.d/consolefont – это один из тех шрифтов, что был установлен выше. Выглядит несколько непривычно (рис. 1), но весьма аккуратно; единственное, к чему я в нём ещё не привык – это к русской «к», которая выглядит как латинская «k», с высоким «хвостиком».
Рисунок 1. Занимаемся русификацией системы В /etc/conf.d/keymaps соответствующие строки приводим к виду: KEYMAP=”-u ru4” SET_WINDOWKEYS=”yes” DUMPKEYS_CHARSET=”koi8-r” Ключик «-u» в раскладке говорит об использовании Unicode. Таблица перекодировки здесь не требуется, но нужно указать кодировку, на которую система будет опираться (третья строка). Всё – после перезагрузки вы должны получить работающую с русскими (точнее, с кириллическими) буквами консоль. Переключение с американской на русскую раскладку и наоборот выполняется клавишей . Вы даже можете создавать файлы с русскими именами: # echo $LANG
# date
# touch файл # ls –a
# cat файл
Можно даже немножко пошалить: # alias см=”view” # см файл Только не нужно этим злоупотреблять – всё же компьютерный мир не настолько совершенен, чтобы подобная «вольность» не обернулась где-нибудь сообщениями об ошибках. Некоторые приложения, которые были установлены до перехода на Unicode, возможно, придётся пересобрать (используя ключ --newuse). Например, это может потребоваться для правильной работы консольного браузера links. Чтобы нормально заработал Midnight Commander, его рекомендуется собирать со следующими флагами: # USE=”unicode slang -ncurses” emerge mc В итоге вы получите приятный на вид и в целом даже русифицированный файловый менеджер (см. рис. 2).
Рисунок 2. Midnight Commander во всей красе Кстати, чтобы в том же links наслаждаться результатом наших трудов, проделайте следующее:
Теперь странички будут отображаться кириллицей вместо транслита (см. рис. 3), да и сам браузер будет общаться с вами преимущественно по-русски.
Рисунок 3. Не так уж и плох links… Подробнее о проблемах кириллизации можно почитать в статье Алексея Барабанова «Кириллизация в Linux» («Системный администратор», март 2006 г.). Счастливого пути! Итак, мы рассмотрели основы, необходимые для того, чтобы начать работать с Gentoo. Конечно, многие вопросы остались за кадром (наиболее крупный из них – установка и настройка X-Window, хотя эта тема относится уже не столько к Gentoo, сколько к самой графической подсистеме). Тем не менее главное – сделать первый шаг. Я не тешу себя надеждой, что сотни и тысячи читателей сразу же бросятся устанавливать эту, в общем-то, довольно специфичную (где-то даже странную) ОС. Но если мои статьи позволят хотя бы ещё одному человеку найти систему своей мечты, то я буду считать свою миссию выполненной. В общем: # USE=”gentoo” emerge freedom ;) Приложение Не забудьте подправить fstab В прошлый раз мы рассмотрели инсталляцию Gentoo. Обратите внимание на ещё один важный для успешной перезагрузки момент – необходимо привести в соответствие с вашими дисковыми разделами файл /etc/fstab, поскольку в базовой системе он представляет собой просто шаблон. Для того чтобы система нормально перезагрузилась, в нём нужно исправить включения «BOOT», «ROOT», «SWAP» на обозначение реальных разделов (строки для файловых систем, которые вы не создавали отдельно, нужно закомментировать или удалить). Впрочем, попытка перезагрузиться без нужных исправлений сразу же укажет вам на проблему. Freetoo или GeBSD? Время от времени на страницах различных сайтов проскакивают новости об одном интересном проекте – Gentoo/FreeBSD. Смысл его – построение системы на основе Gentoo (инструментарий GNU, система Portage и т. д.), но на ядре FreeBSD. В качестве основной причины, побудившей создать столь странный проект, называется желание распространить Portage на другие операционные системы и тем самым влить в неё «новую кровь» и ускорить её развитие. Безусловно, идея заслуживает внимания. Хотя бы в том плане, что единство – это то, чего так не хватает миру Open Source. Возможно, Gentoo/FreeBSD будет хорошим выбором для администраторов, которым по тем или иным причинам необходимы обе системы, поскольку позволяет унифицировать работу с дополнительным программным обеспечением. С другой стороны, очень сомнительно, что найдётся много желающих серьёзно работать с подобной системой. Пользователи Gentoo и так довольны, а мнение большинства «обладателей» FreeBSD, думаю, хорошо отражает комментарий, который я прочёл на одном из форумов: «Я не знаю, что такое Portage, но оно нам во FreeBSD не надо!». Как бы то ни было, сейчас проект находится, скорее, в зачаточном состоянии. Что из этого получится – время покажет. Дополнительную информацию можно получить на странице проекта: http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd, а также по адресу: http://en.wikipedia.org/wiki/Gentoo/FreeBSD. Справедливости ради замечу, что такая же участь постигла и другие BSD-системы. С другой стороны, подобный «нездоровый» интерес к FreeBSD проявляет и Debian (см. http://www.debian.org/ports/kfreebsd-gnu). Нет предела совершенству Безусловно, утилита emerge позволяет делать очень много. Но «чтобы было ещё веселее», поставьте пакет gentoolkit. Он содержит несколько полезных утилит, делающих работу с Portage ещё более приятной:
Подробности использования каждая из этих программ выведет вам сама, будучи запущенной без параметров. |
Сергей Супрунов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
