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

В семействе команд apt имеется синтаксический аналог команды apt-get под названием apt-build. Для чего он нужен? Загляните в список доступных репозиториев командой cat /etc/apt/sources.list. Видите закомментированные символом решётки строки, начинающиеся с deb-src? Это репозитории, содержащие скрипты для самостоятельной компиляции, сборки и установки deb-пакетов. Почему они закомментированы и зачем нужны? Закомментированы они, чтобы неофиты их не использовали. Для них – готовые deb-пакеты, управляемые командой apt-get. Причём эти пакеты нередко скомпилированы для компьютеров уровня 386, что гарантирует их работоспособность практически на любом компьютере. У вас наверняка компьютер получше, но скорость работы готового софта из репозитория не самая высокая. Короче, если вы не желаете употреблять то, что вам приготовили – готовьте сами с помощью apt-build. Не беспокойтесь -- никаких "страшных" команд вроде cоnfigure, make или make install вам не понадобится. Всё предельно автоматизировано! Однако, подводные камни всё же есть.

По умолчанию команда apt-build отсутствует, поэтому установим её: sudo apt-get install apt-build Начнётся скриптовая установка команды apt-build, в процессе которой вам будет задано несколько вопросов. Три совета. Во-первых, устанавливайте средний уровень оптимизации, во-вторых, согласитесь, что deb-файл для команды apt-build будет добавлен в репозиторий (иначе вы не сможете обновлять эту команду), в-третьих, отметьте именно свой класс компьютера. Например, если у вас многоядерник, то отмечайте core2. В процессе установки автоматически подтянется также куча пакетов, необходимых для компиляции и сборки. Затем в файле /etc/apt/sources.list любым редактором надо раскомментировать строки, начинающиеся с deb-src. Обязательно надо проиндексировать новые источники командой sudo apt-build update Прежде, чем оптимизировать ранее установленный пакет – удалите его. Как это сделать, вы знаете. А если не знаете, то целесообразнее ничего не компилировать и дальше не читать. Кстати, экспериментально установлено, что опция reinstall в команде apt-build срабатывает не всегда. Информация о директории для сборки, опции компилятора, архитектура вашего процессора сохраняется в директории /etc/apt/apt-build.conf. При желании можно кое-что подредактировать вручную, например, повысить уровень оптимизации, но удобнее файл apt-build.conf изменять командой sudo dpkg-reconfigure apt-build. Запустите её и снова ответьте на вопросы, причём в дополнительных параметрах для make обязательно уточните количество ядер, указав их, как -jN, где N -- число на единицу больше, чем количество ядер вашего компьютера. Т.е. для двухъядерному процессору соответствует -j3, трёхъядерному соответствует -j4 и т.д. Иначе, возможно, программа будет работать с одним ядром. Это ускорит сборку. Всё готово, пора компилировать. Например, так: sudo apt-build install firefox Результат появится в локальном репозитории /var/cache/apt-build/repository

На полчаса-час, а то и больше (в зависимости от производительности компьютера и "веса" исходников) после запуска компиляции ваш компьютер будет занят процентов на 70-80. По окончанию компиляции и сборки, если не было ошибок, полученный продукт подвергнется тестированию, на что потребуется ещё столько же времени. Наконец всё закончится. Если в процессе тестирования будет обнаружена хотя бы одна ошибка, то продукт не будет установлен, и вместо него система установит прежний deb-пакет из репозитория. Если такая неприятность произошла, то идём в локальный репозиторий /var/cache/apt-build/repository и ищем установочный deb-пакет с именем компилируемого пакета. Если такой пакет наличествует, то всё в порядке, ошибки не фатальные, скорее всего имеет место конфликт зависимостей. Опять вычищаем из системы неоптимизированный пакет и любым способом, например, посредством утилиты gdebi, пытаемся установить оптимизированный пакет. Если он не будет устанавливаться из-за конфликтов с какими-либо ранее установленными пакетами, то посмотрите, что это за пакеты, и можно ли их удалить. Например, английские спеллеры для «огнелиса» можно удалить безболезненно. Если конфликтующие пакеты нельзя удалить, то сначала надо попытаться их тоже оптимизировать. После этого надо попробовать повторно установить оптимизированный пакет. Если получилось – принимайте поздравления. Для рабочего стола Unity установите также оптимизированный пакет глобального меню; он, очень вероятно, тоже появился в локальном репозитории /var/cache/apt-build/repository.

Бывает, что ничего путного не получилось, и нет времени и/или желания искать причину, тогда снова устанавливаем неоптимизированный, но работоспособный прежний пакет из штатного репозитория с помощью старой знакомой команды sudo apt-get install или с помощью Центра приложений. :) Оптимизированные приложения всегда работают быстрее неоптимизированных на 2-15%, причём прирост тем больше, чем лучше ваш компьютер. Правда, заметить это на современных "цифродробилках" удаётся далеко не всегда. Тогда резонно спросить: "А зачем оптимизировать-то?" Дело в том, что есть классы приложений, где оптимизация даёт ощутимый эффект. Например, конверторы медиафайлов. Так что, если у вас есть немного времени и желания, то рискуйте. В крайнем случае вы не потеряете ничего. Заметьте: пользователи Windows лишены возможности что-либо оптимизировать подобной пересборкой. :)