$ man 8 aptitude
Ранее уже говорилось, что по умолчанию при использовании aptitude с любыми операторами инсталляции устанавливаемый пакет тянет за собой не только «жесткие», обязательные, зависимости, но и изрядную часть «мягких» – тех, которые майнтайнер пакета посчитал нужным включить в категорию recommends. Что не всегда желательно.
Избежать принудительного выполнения «рекомендаций» можно с помощью опции -R, данной в командной директиве установки конкретного пакета. Если же игнорирование «рекомендаций» требуется всегда – это можно будет запечатлеть в конфигурационном файле. Как именно – будет сказано чуть ниже. Пока же допустим, что мы уже изменили умолчальное поведение aptitude – теперь операторы инсталляции учитывают только «жесткие» (depends) зависимости.
Однако для некоторых пакетов все же желательно установить все рекомендуемые зависимости – например, в случае малознакомых пакетов, с которыми просто лень разбираться. В этом случае можно прибегнуть к опции -r (--with-recommends), которая инвертирует действие опции -R – то есть заставит установить все рекомендуемые зависимости.
Должен предупредить: применение опции -R к установленной системе Ubuntu/Kubuntu требует осторожности. Базовая ее инсталляция осуществляется по принципу «плюс recommends». И применение к ней aptitude -R делает как бы «ненужными» многие пакеты. Одни из них – действительно (на мой взгляд) лишние. Однако в «черный список» могут попасть и нужные библиотеки. Так что перед тем, как нажать <Enter> в ответ на предложение
Хотите продолжить? [Y/n/?]
внимательно прочтите весь предшествующий ему вывод.
Тем не менее, вполне возможно, что по разрешении указанных противоречий, опцию -R все же захочется сделать умолчальной. Для этого нужно внести изменения в конфигурационные файлы aptitude. Вообще-то aptitude обращается к тем же конфигам, что и apt (/etc/apt/sources.list, /etc/apt/apt.conf),однако имеет и собственный – ~/.aptitude/config. По умолчанию он пуст, но может быть отредактирован по потребностям. В частности, для придания опции -R статуса по умолчанию, в этот файл следует внести такую строку:
aptitude::Recommends-Important «false»;
К слову сказать, можно, напротив, сделать так, чтобы при установке пакета автоматически инсталлировались также и «предлагаемые» (suggest) зависимости. Это достигается строкой
aptitude::Suggests-Important «true»;
Вообще-то опций конфигурирования для aptitude предусмотрено великое множество – и многие из них применимы не только к командному, но и к интерактивному режиму, позволяя настроить внешний вид интерфейса и многое другое. Ознакомиться с полным набором опций конфигурирования aptitude и их умолчальными значениями можно в официальной документации – она влючена в состав дистрибутива и находится в каталоге /usr/share/doc/aptitude/html/{lang}/. Здесь под {lang} подразумевается язык документа – кроме английской (en) версии, в репозитории Ubuntu существуют переводы его на французский, финский и чешский языки; кстати, в репозитории Debian русской версии этого документа также не обнаруживается. А текущие настройки можно посмотреть в файле /usr/share/aptitude/aptitude-defaults.
В общем, после знакомства с aptitude можно сделать вывод, что она предоставляет все возможности, обеспечиваемые утилитами apt-get и apt-cache плюс ряд дополнительных, подчас неоценимых, удобств, позволяющих, в частности, содержать пакетное хозяйство в стерильной чистоте. И потому использование ее в командном режиме предпочтительно перед указанными средствами комплекта apt.
Правда, тут я хотел бы отметить: совместное использование aptitude и apt видится мне нежелательным. То есть, по завершении настройки aptitude и приведении пакетного хозяйства с соответствие с ними к командам apt-get и apt-cache лучше не прибегать. Команда же apt-cache будет выдавать информацию в соответствие с настройками aptitude, а не умолчаниями apt – в частности, зависимости в выводе apt-cache show будут показываться так, как они описаны в файле ~/.aptitude/conf.
Что же до интерактивного режима aptitude, требующего запоминания многочисленных горячих клавиш, – это на любителя. Хотя в некоторых случаях – например, при чистке системы от категорий пакетов – и он может оказаться незаменимым.
В заключение я хотел бы выразить признательность Тихону Тарнавскому, благодаря которому я преодолел скептическое отношение к этой замечательной программе.
Zenwalk Linux: не его ли учить?
LinuxFormat #112 (декабрь 2008, DVD-версия)
В LXF108 была опубликована колонка, озаглавленная просто: «Какой Linux изучать?». В этой статье я готов предложить дальнейшее развитие заявленной в ней темы.
Самой модной темой для обсуждений в российском сообществе в последнее время стало повсеместное внедрение Linux в школах, вузах, на производстве... да разве всё перечислишь? Судя по тому, что одно из российских зеркал сайта www.kernel.org расположено на сервере perespim.ru, не за горами и внедрение этой ОС в сфере, так сказать, интимной. Желающих убедиться прошу сюда: http://kernel.perespim.ru/pub/linux/; кстати, вопреки присказке, что «быстро хорошо не бывает», зеркало вполне шустрое.
Так что ответ на вопрос, кого учить Linux, более или менее ясен: всех. Сложнее с ответом на другой вопрос: а кто будет учить? Ибо повсеместное внедрение Linux требует знания предмета, как минимум, от тех, кто это внедрение будет осуществлять. А здесь наблюдается напряжёнка: наша страна за годы существования этой ОС не вырастила достаточного количества специалистов – их еще самих предстоит обучить.
Это выводит нас на третий вопрос: а какому именно Linux следует учить будущих гуру – внедренцев этой системы в масштабе страны (а то, глядишь, и в мировом)? А может, их вообще следует учить FreeBSD или, скажем, DragonFly BSD?
На www.distrowatch.com на сегодняшний день зарегистрировано около 350 активно развиваемых дистрибутивов (включая полторы дюжины BSD-систем), плюс еще пара сотен проектов, которые тоже нельзя не учитывать: реанимация давно, казалось бы, умерших начинаний – отнюдь не редкость в мире Open Source. Но все ли они одинаково полезны для информационного здоровья будущих Linux-гуру?
Сконцетрируемся всё-таки только на активно развивающихся проектах, в рамках того же Distrowatch'а разделяемых на два десятка категорий . Среди них для начала отфильтровываем узкоспециализированные решения: кластерные, восстановительные, security-системы; все они предназначены для тех, кто «уже умеет» (и, главное, знает, для чего ему они нужны).
Следующий фильтр ставим перед дистрибутивами с ярко выраженной национальной спецификой. Например, чуть ли не в каждой провинции Испании есть свой Linux, учитывающий диалектные особенности, специфику местного делопроизводства, и прочие детали. Что, разумеется, очень важно для местных пользователей (и должно служить примером для других стран и регионов), но вряд ли актуально для нашего государства.
Далее, исключаем из рассмотрения дистрибутивы, разрабатываемые отдельными лицами, вокруг которых не сложилось (ещё не сложилось?) более или менее развитого сообщества. Не потому, что индивидуалы не способны сделать ничего путного, как раз напротив: мы знаем массу примеров успешно развивающихся проектов, начатых одним-единственным человеком. К сожалению, известны и другие прецеденты: когда инициатор разработки по тем или иным причинам переставал заниматься своим детищем, а подхватить эстафету было некому.
При всей моей любви к BSD-системам, их пока тоже придется исключить из числа кандидатов. Причин тому много, и останавливаться на них здесь я не стану – будем считать это просто волюнтаристским решением.
Наконец, на заключительном этапе можно отобрать просто малоизвестные дистрибутивы. Не потому, что они плохи сами по себе: просто по ним, как правило, трудно найти информацию в достаточном количестве. А информационное обеспечение – далеко не последний критерий выбора системы, которую должны осваивать будущие внедренцы...
Но и после такого многоступенчатого отбора список кандидатов остаётся более чем обширным. Правда, и мнений относительно того, как сделать окончательный выбор, оказывается не намного меньше. Тем не менее, наиболее распространенных точек зрения – две. Согласно первой, будущие гуру должны учиться на наиболее дружественных к пользователю системах, таких, как Fedora и прямые клоны Red Hat, вроде CentOS или Scientific Linux (о самом RHEL тут речи нет из-за дороговоизны технической поддержки, да и ненужности её в данной ситуации), SUSE, Ubuntu, Mandriva, ALT Linux – тем более, что некоторые из них уже пустили корни в российских школах. Список неполон, но его уже достаточно, чтобы было над чем задуматься.
Преимущества такого подхода лежат на поверхности: начинающие пользователи начинают знакомство с новой операционной системой в относительно привычной им обстановке. По таким популярным дистрибутивам проще найти информацию: и в виде книг, и в Сети. Недостатки же не столь очевидны, но от этого не становятся менее весомыми. Во-первых, это сложность «докапывания» до устройства системы. Кажущаяся простота может создать иллюзию понимания и лишить стимулов у детальному разбирательству – не будем забывать о том, что речь идет не о конечных пользователях, а о тех, кому со временем придётся учить других.
