Меню Рубрики

Установка из пакетов опции

Установка пакетов Ubuntu

Установка новых программ — один из самых важных моментов при работе с вашей системой. Раньше мы уже рассматривали добавление PPA в систему и установку программ из исходников. Но даже в PPA есть далеко не все пакеты, а установка из исходников слишком сложна для новичков.

Нередко возникает необходимость поставить программу, для которой уже есть собранные deb пакеты в интернете. Это может быть какая-нибудь не очень популярная программа или даже драйвера, которые вы скачали и хотите установить на компьютер где нет сети. На компьютере без сети установка программ с флешки ubuntu может стать единственным решением. В этой статье будет рассмотрена установка deb пакетов в ubuntu. Мы рассмотрим где их взять и как установить deb в ubuntu.

Где взять deb пакеты?

Ответ прост — на просторах интернета. Если это нужная вам программа, то вы уже знаете где взять для ее пакет. В случае с драйверами ситуация немного сложнее. Все программы и драйвера, которые находятся в официальных репозиториях Ubuntu вы можете найти на сайте launchpad.net, это очень удобно, если на машине, где они должны быть установлены нет интернета. Например, ищем linux-firmware и открываем ее страницу на Launchpad, внизу выбираем версию программы:

Дальше выбираем архитектуру:

И осталось получить deb файл для нашей системы:

Если у вас есть другой компьютер с интернетом или вы планируете устанавливать программы потом, а сейчас нужно только скачать deb пакеты, то это можно сделать с помощью apt:

Пакет будет сохранен в текущей папке и дальше вы сможете все без проблем установить. Но будет скачан только сам пакет, без его зависимостей. Зависимости мы можем получить только в системе с интернетом используя команду apt-rdepends:

apt download имя_пакета $(apt-rdepends имя_пакета|grep -v «^ «)

Теперь у вас есть не только пакет, но и все его зависимости.

Установка deb пакетов Ubuntu

Установить Deb пакет Ubuntu не так уж сложно, для этого даже есть несколько утилит. Можно устанавливать как с помощью графического интерфейса, так и в терминале.

Самый простой способ установки — в графическом интерфейсе, с помощью центра приложений, с него и начнем. Откройте файловый менеджер в папке с пакетом:

Выполните двойной клик по deb пакету, далее откроется центр приложений, где вы посмотреть информацию о пакете и запустить установку нажав кнопку установить.

Установка программ Ubuntu с помощью центра приложений мне не очень нравится, он обычно очень долго думает и не всегда правильно открывает программу, но можно воспользоваться другой графической утилитой — gdebi. Сначала ее нужно установить:

sudo apt-get install gdebi

Теперь кликаем правой кнопкой мыши по файлу, выбираем открыть с помощью и gdebi:

Дальше осталось нажать кнопку установить и дождаться завершения установки пакета ubuntu. Программа автоматически установит все зависимости, если есть доступ к сети.

Установка deb из консоли Ubuntu выполняется не намного сложнее. Для этого используется утилита dpkg. Сначала переходим в папку куда был загружен deb пакет:

sudo dpkg -i имя_пакета.deb

Для этой команды доступны символы сокращений, например, можно написать вот так, чтобы установить все deb пакеты из этой директории:

Программа не умеет разрешать зависимости, даже если есть доступ к сети, она только устанавливает пакет, поэтому для установки зависимостей после установки deb ubuntu выполните:

Теперь, когда зависимости были загружены, вы можете запускать и использовать программу.

Это не единственный способ установки пакетов ubuntu через терминал, утилиту gdebi тоже можно запустить таким способом:

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

sudo apt install ./имя_пакета.deb

Программа автоматически установит все зависимости и больше ничего не придется выполнять.

Выводы

Вот и все. Теперь установка deb пакетов в Ubuntu не вызовет у вас проблем. Оказывается, есть несколько способов установки программ в ubuntu и все они имеют свои преимущества. Если у вас остались вопросы, спрашивайте в комментариях!

источник

Управление пакетами

Установщики пакетов

Для выполнения всех операций над пакетами требуется специальная программа – установщик пакетов . В ее задачи входит весь цикл работ с пакетом : от создания пакета (компиляции исходного пакета в двоичный), до его установки, удаления, обновления, а также хранение и вывод по запросу пользователя или системы информации об установленных и неустановленных пакетах, принадлежащих им файлах и т. п.

В Linux формат пакетов не унифицирован, распространено несколько различных форматов, и для каждого из них требуется собственный установщик пакетов . Наиболее известны уже описанный rpm , dpkg , используемый в Debian (см. подробнее лекцию 18), а также пакеты в формате tgz (он же tar.gz – файловый архив tar , сжатый упаковщиком gzip , GNU Zip ), то есть обычные файловые архивы, где вся необходимая в пакете метаинформация упакована в виде файлов наряду с файлами программного обеспечения. Установщики пакетов различаются не только форматом пакетов, с которыми они работают, но и кругом возможностей, внутренним форматом хранения информации и т. д.

Установщик пакетов. Программа, выполняющая основные операции с пакетами: установку, удаление, проверку, вывод информации о пакетах.

В рамках этой лекции мы ограничимся обсуждением только одного из установщиков пакетов – rpm ( Red Hat Package Manager ). Он первоначально возник в дистрибутиве RedHat, но в настоящее время используется и во многих других дистрибутивах. Пожалуй, сейчас его можно назвать самым распространенным форматом: авторы программ для Linux обычно выкладывают свои программы в Internet в виде файловых архивов tgz и пакетов rpm .

Обратной стороной популярности rpm является его нестандартность. Под расширением .rpm довольно редко оказывается канонический формат, разрабатываемый RedHat. В формате rpm усматривают много недостатков и недоделок, поэтому распространено множество усовершенствованных и дополненных версий rpm , и, соответственно, пакетов, ориентированных на какую-нибудь из этих версий, но носящих все то же расширение. На практике это означает, что разные версии rpm не полностью совместимы между собой, поэтому даже если в вашей системе используется rpm , из этого совершенно не следует, что вы сможете установить любой найденный в Internet пакет в этом формате.

Случай rpm – только самое яркое проявление более общей проблемы: в общем случае ни в одном дистрибутиве нельзя без потерь, помех или ручного вмешательства установить пакет , не разработанный специально для данного дистрибутива. В следующем разделе ( «Менеджеры пакетов» ) изложены некоторые соображения, почему это нежелательно, и почему следует по возможности пользоваться именно «родными» пакетами,а если их нет – создавать их самостоятельно.

Другая проблема установщиков пакетов заключается в том, что они годятся только для установки/удаления отдельных пакетов, но не предназначены для доставки пакетов в системы ( пользователь сам должен найти и скачать нужный пакет , а также указать местоположение файла пакета установщику в командной строке). Кроме того, установщик работает с каждым пакетом по отдельности: он может указать, что не удовлетворены некоторые зависимости, или имеют место конфликты, но не в состоянии в ходе процедуры установки ни установить все необходимые пакеты по цепочке зависимостей, ни удалить конфликтующие – пользователь должен делать это вручную. Установщики пакетов не предоставляют также никаких средств по автоматизации обновления системы.

Менеджеры пакетов

Установщики пакетов делают атомарными (одношаговыми) операции с отдельными пакетами: вместо копирования множества файлов и запуска нескольких сценариев пользователь вводит одну команду «установить/удалить пакет «. Атомарная с точки зрения пользователя операция – добавление в систему одного нового компонента может состоять из нескольких (и даже многих) операций над пакетами. Мефодий уже столкнулся с подобным случаем, изучая на собственном опыте понятие «цепочка зависимостей». Здесь установщики пакетов никак не могут облегчить работу пользователя. Чтобы сделать процедуру установки, удаления и обновления компонента системы атомарной, были разработаны менеджеры пакетов . Менеджер пакетов – это программа , вычисляющая весь комплекс операций над отдельными пакетами, который нужно произвести для установки/удаления нового компонента ( пакета ), и сама запускает установщик пакетов необходимое количество раз с соответствующими параметрами. Кроме того, менеджер пакетов хранит информацию не только о пакетах, уже установленных в системе, но и обо всех, которые доступны для установки с какого-либо носителя или по Сети (подробнее об этом в разделе «Доставка»).

Менеджер пакетов. Программа, выполняющая установку, удаление или обновление любого пакета или группы пакетов и автоматически выполняющая все необходимые для этого процедуры (доставку пакетов из удаленных репозиториев, вычисление зависимостей и установку требуемых по ним пакетов, удаление замещаемых пакетов и т. п.).

Наиболее известный и популярный менеджер пакетов называется APT ( Advanced Package Tool). Первоначально он был разработан в рамках дистрибутива Debian и работал только с установщиком пакетов dpkg , впоследствии для других дистрибутивов была разработана версия, работающая с rpm . В дистрибутиве Мефодия также используется APT .

Читайте также:  Установка ангельские глазки для мазда 3

Чтобы установить пакет , прежде всего нужно узнать о его существовании. Пакетов для каждого дистрибутива Linux доступны тысячи и даже десятки тысяч, и ориентироваться в них непросто. APT предоставляет возможность поиска нужного среди доступных пакетов, для этого используется утилита apt -cache . В каждом пакете обязательно имеется краткая аннотация (в одну строку) и небольшое описание содержащихся в пакете ресурсов (не длиннее нескольких абзацев). По команде » apt -cache search подстрока » APT найдет и выведет список из имен и аннотаций пакетов, где в имени, аннотации или описании нашлась указанная подстрока :

Для установки и удаления пакетов предназначена утилита apt -get , а команда установки выглядит совсем просто: » apt -get install имя_пакета » , причем не нужно указывать никаких сведений о версии и местонахождении пакета : APT сам найдет и установит самую последнюю из доступных версий:

Процедуру установки APT выполняет в несколько этапов: сначала он ищет запрошенный пакет в списках доступных, найдя, рассчитывает, какие пакеты следует установить, чтобы удовлетворить его зависимости, после чего получает файлы всех нужных пакетов (в данном случае APT нашел нужные пакеты на диске CD-ROM ) и запускает установщик пакетов последовательно для установки всего необходимого. Аналогично, чтобы удалить пакет , достаточно выполнить команду » apt -get remove имя_пакета » .

Кроме APT , есть еще несколько менеджеров пакетов . Большинство из них специфичны для определенного дистрибутива, как, например, emerge для Gentoo или YaST для SuSE. Их задачи и возможности примерно совпадают с APT .

источник

Yum, шпаргалка

Шпаргалка по работе с пакетным менеджером Yum (Yellowdog Updater, Modified), который используется в популярных Linux дистрибутивах: RedHat, CentOS, Scientific Linux (и других). В целях экономии места вывод команд не представлен.

Оглавление

список названий пакетов из репозиторий

список всех доступных пакетов

список всех установленных пакетов

установлен ли указанный пакет

список установленных и доступных пакетов

список пакетов, относящихся к ядру

отображение информации о пакете

список зависимостей и необходимых пакетов

найти пакет, который содержит файл

поиск пакета по имени и описанию

получить информацию о доступных обновлениях безопасности

вывести описание и содержимое группы

установка группы пакетов «Basic Web Server»

Проверка на доступные обновления

список подключенных репозиториев

информация об определенном репозитории

информация о пакетах в указанном репозитории

установить все пакеты из репозитория

удалить пакеты установленные из репозитория

проверить локальную базу rpm (поддерживаются параметры dependencies, duplicates, obsoletes, provides)

просмотр yum истории (вывод списка транзакций)

просмотр информации определенной транзакции (установленные пакеты, установленные зависимости)

дополнительно можно просмотреть лог

удалить пакеты сохраненные в кэше

удалить все пакеты и метаданные

обновить до определенной версии

установить из локальной директории (поиск/установка зависимостей будут произведены из подключенных репозиториев)

откатиться к предыдущей версии пакета

переустановка пакета (восстановление удаленных файлов)

удаление ненужных более пакетов

создание локальных репозиториев (createrepo ставится отдельно)

установка обновлений по расписанию (yum-cron устанавливается отдельно)

Опции Yum

использовать Yum без плагинов

или отключить определенный плагин

включить плагины, которые установлены, но отключены

включить отключенный репозиторий

скачать пакеты, но не устанавливать
(на Centos 7 x86_64 будут скачаны в ‘/var/cache/yum/x86_64/7/base/packages/’)

Cледующие команды доступны после установки пакета yum-utils

найти из какого репозитория установлен пакет

найти процессы, пакеты которых обновлены и требуют рестарта

запрос к репозиторию, узнать зависимости пакета, не устанавливая его

синхронизировать yum репозиторий updates в локальную директорию repo1

проверить локальный репозиторий на целостность

установить необходимые зависимости для сборки RPM пакета

управление конфигурационными опциями и репозиториями yum

запрос к локальной базе yum, отображение информации о пакете
(использованная команда, контрольная сумма, URL с которого был установлен и другое)

скачать rpm пакеты из репозитория

скачать src.rpm пакет из репозитория
(должен быть подключен соответствующий репозиторий, например в ‘/etc/yum.repos.d/CentOS-Sources.repo’ в CentOS)

Конфигурационные файлы Yum и их расположение

Основной конфигурационный файл

директория, с конфигурациями (например, yum плагины)

директория, содержащая информацию о репозиториях

Некоторые опции yum.conf:

Директория, где yum хранит кэш и файлы базы (по умолчанию ‘/var/cache/yum’)

Определяет должен или нет Yum хранить кэш заголовков и пакетов после успешной установки. Значения: 0 или 1. (по умолчанию 1)

уровень вывода отладочных сообщений. Значения: 1-10 (по умолчанию 2)

лог файл (по умолчанию ‘/var/log/yum.log’)

обновлять устаревшие пакеты

проверка подписи пакетов. Значения: 0 или 1 (по умолчанию 1)

включение плагинов. Значения: 0 или 1 (по умолчанию 1)

Некоторые полезные плагины

Добавляет опцию командной строки для просмотра ченжлога перед/после обновлениями

выбирает более быстрые репозитории из списка зеркал

добавляет команды keys, keys-info, keys-data, keys-remove, которые позволяют работать с ключами.

блокировать указанные пакеты от обновления, команда yum versionlock

добавление команд yum verify-all, verify-multilib, verify-rpm для проверки контрольных сумм пакетов

Работа Yum через прокси сервер

Для всех пользователей:
добавить в секцию [main] в /etc/yum.conf

при необходимости указать пароль, добавить

указать прокси для отдельного пользователя

Буду рад любым дополнениям и замечаниям.
Дополнительно читайте:

источник

Как создавать, собирать, устанавливать и использовать пакеты с программами и библиотеками для UNIX-подобных систем

Речь пойдёт о программах и библиотеках для UNIX-подобных систем, распространяемых в виде исходного кода (в том числе в виде тарболлов), написанных обычно на C и C++ (хотя этот же порядок работы может применяться к софту на любом языке). Многие вещи в этой статье написаны применительно конкретно к GNU/Linux, хотя многое из статьи может быть обобщено и на другие UNIX-подобные ОС.

Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта (UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле).

В этой статье я разберу следующие вопросы:

  • Вот скачал программу или библиотеку. Как её собрать и установить? Как воспользоваться библиотекой?
  • Что такое префикс (prefix) установки? В чём разница между сборкой и установкой? Куда обычно устанавливают программы?

Я разберу только совсем базовые вещи. Те, которые типичные участники сообщества свободного ПО, программирующие на C и C++ под UNIX-подобные системы, обычно уже знают. Как создавать тарболлы (на примере «голого» make) и как устанавливать чужие тарболлы. Advanced советы по созданию «хороших» пакетов я не дам. «Продвинутые» вещи читайте в документации систем сборки, в замечательной статье «Upstream guide» от Debian (в её конце есть ещё куча ссылок о создании «хороших» пакетов). Многое в этой статье можно было сделать по-другому, моя цель: дать хотя бы один способ, не пытаться объять необъятное.

Предупрежу: начало будет совсем простым, но ближе к концу будет всё поинтереснее.

И ещё одно предупреждение. Я написал эту статью наскоро для одного человека. А после написания подумал, мол, раз уж написал, выложу уж на Хабр, чтоб не пропала. Поэтому в статье есть недочёты типа нечёткого структуирования статьи, фраз типа «не осуществляет сама инклудивание» и пр. Я это исправлять не буду. Может когда-нибудь в следующей жизни, когда руки дойдут. Выбор был между тем, чтобы публиковать так или не публиковать вовсе.

Итак, начнём мы с того, что создадим пакет с программой Hello, world. Для начала определимся с системой сборки.

Собственно, сама сборка пакета обычно осуществляется с помощью программы make (хотя это не единственный путь). Конфиг для make обычно лежит в файле под названием Makefile.

Есть несколько вариантов: просто использовать make либо использовать совместно с make некую высокоуровневую систему сборки (обычно autotools или cmake), которая будет, собственно, генерировать конфиги для make.

Мы в нашем примере будет использовать только make для простоты. Итак, создаём hello.c:

Внимание! Работает на GNU/Linux. Работа под macOS не гарантируется! Этот Makefile не является портируемым вообще на все UNIX-подобные системы! Подробнее будет дальше.

здесь означает символ табуляции.

Это далеко не единственный способ написать этот Makefile. Вообще, цель всей моей статьи — дать некую базу. Что ещё можно в этом Makefile изменить, вы можете потом узнать из других источников.

Также в этой статье я предполагаю, что вы знаете уж совсем базовые вещи про make. Я имею в виду, что вы знаете, что Makefile — это описание дерева зависимостей, и что он нужен, чтобы собрать ровно те файлы, которые нуждаются в сборке. В этой статье я расскажу про использование make при создании пакетов, про «виртуальные» цели make такие как install и all. Ещё я предполагаю, что вы уже знаете совсем базовые вещи про то, как запускать компилятор из командной строки, т. е. вы знаете, что такое cc -o hello hello.c .

Итак, теперь давайте разбирать наш Makefile.

Для начала скажу следующее. Допустим, пользователь скачал пакет. Ему нужно сперва собрать его, т. е. получить бинарники в каталоге с самим пакетом (либо в случае out of tree build получить их в неком другом каталоге, что не меняет сути), а затем установить, т. е. скопировать полученные бинарники в место их окончательного хранения в системе.

Читайте также:  Установка вебасто на лада веста

То есть смотрите. Вы залогинены под юзером user. Ваш домашний каталог /home/user. Вы скачали пакет, распаковали его, скажем в /home/user/Desktop/foo. Далее вы его собрали. Собрали в этой же папке, /home/user/Desktop/foo. Либо, если речь идёт об out of tree build, вы создали ещё одну папку /home/user/Desktop/foo-build и собрали в ней. Теперь, после сборки вы решаете установить её в /usr/local. Вот тут уже вам нужны права root. Вы при помощи sudo устанавливаете эту программу в /usr/local.

Пара слов о размещении каталогов в системе. Разберу лишь некоторые каталоги. Более подробную информацию можно найти в Filesystem Hierarchy Standard (поддержан многими дистрибутивами GNU/Linux) и по команде «man 7 hier» в GNU/Linux и, возможно, других ОС. Во всяком случае я расскажу, как они были устроены, скажем, лет пять назад (т. е. где-то в 2012-м году), всякие новые веяния типа недавнего нововведения в Fedora «давайте-ка мы всё переместим в /usr» я рассматривать не буду.

  • /bin — это бинарники (т. е. испоняемые файлы), важные для работы системы на ранних стадиях загрузки.
  • /sbin — это то же самое с тем отличием, что эти бинарники обычно может запускать только root.
  • /lib — бинарные файлы библиотек, нужные для программ из /bin и /sbin
  • /usr — «вторая иерархия файлов», т. е. это как бы «ещё один /»
  • /usr/bin — то же, что /bin, но на этот раз это бинарники, некритичные для загрузки
  • /usr/sbin — то же, что /sbin, но опять-таки, некритичные для загрузки
  • /usr/lib — бинарные файлы библиотек, которые не нужны для программ из /bin и /sbin
  • /usr/include — хедеры библиотек
  • /usr/local — «третья иерархия файлов», она опять содержит /usr/local/bin, /usr/local/sbin, /usr/local/lib и /usr/local/include, на этот раз эти каталоги предназначены для «локального администратора». Что это значит? Это значит, что (в случае дистрибутивов GNU/Linux с пакетным менеджером) каталоги, о которых речь шла до этого, находятся под контролем пакетного менеджера. А вот каталоги внутри /usr/local находятся в распоряжении «локального администратора», т. е. вас. Если вы хотите поставить что-то из сорцов, в обход менеджера пакетов, то можно поставить туда.

Теперь по поводу prefix. Когда вы устанавливаете какой-нибудь пакет, вы должны указать ему так называемый prefix, т. е. каталог, в который всё будет установлено. В этом каталоге будет создан подкаталог bin, в него будет установлены бинарники, будет создан подкаталог lib, туда будут установлены бинарные файлы библиотек, и т. д.

То есть, например, вы устанавливаете пакет, указывая ему prefix /usr/local. Тогда бинарники пойдут в /usr/local/bin, бинарные файлы библиотек — в /usr/local/lib и так далее.

Теперь вернусь к разбору Makefile. PREFIX — это и есть тот prefix, про который я сейчас говорил. В качестве дефолтного префикса (пользователь сможет его переопределить) у нас указан /usr/local — хороший дефолтный выбор. Обычно его всегда указывают в качестве дефолтного префикса при создании пакетов (к сожалению, некоторые пакеты этого всё же не делают, дальше будет подробнее). Далее идёт CC. Это стандартное название для переменной make, в которую кладут компилятор, в данном случае cc. cc — это в свою очередь обычно используемая команда для запуска компилятора по умолчанию в данной системе. Это может быть gcc или clang. На некоторых системах команда cc может отсутствовать. CFLAGS — стандартное название для переменной с флагами компиляции.

Если просто набрать make, то будет выполнена та цель, которая идёт в Makefile первой. Обычная практика в том, чтобы называть её all. И такая цель обычно собирает весь проект, но ничего не устанавливает. Эта цель обычно «виртуальная», т. е. у нас нет файла под названием all. Т. к. наша задача собрать лишь один бинарник hello, то мы просто делаем all зависящим от hello. Далее идёт описание цели сборки hello. Его можно было в принципе разбить на два этапа: сборка hello.o из hello.c и сборка hello из hello.o. Я так делать не стал для простоты.

Далее идёт install, установка. Это тоже виртуальная цель. Она зависит от all. Это сделано на случай, если пользователь сразу наберёт «make install», без «make». В этой цели мы сперва создаём папку, куда будем устанавливать, т. е. как и следовало ожидать, $(PREFIX)/bin, а затем устанавливаем в неё утилитой install.

Что делает install? Это почти то же, что и cp. Точные отличия я и сам не знаю. Для установки программ нужно использовать install, а не cp.

Бинарник устанавливается в $(PREFIX)/bin, потому что именно так и нужно делать. Бинарники идут в подкаталог bin в prefix, бинарные файлы библиотек — в lib в PREFIX и т. д.

Здесь я предполагаю, что у вас на системе установлен так называемый BSD install. В GNU/Linux’е он есть. В некоторых системах его может не быть. Может быть какой-нибудь другой install, который в этой ситуации не сработает. Именно это я имел в виду, когда сказал, что работа в разных ОС не гарантируется.

Здесь я не рассматривал DESTDIR, который, между прочим, крайне рекомендуется использовать в Makefile. Я даже не рассматривал цель clean.

Окей, давайте теперь создадим окончательный тарболл, так называют файл с расширением .tar.gz, .tar.xz и так далее. Поместите файлы hello.c и Makefile в папку hello-1.0 (принято указывать номер версии при создании тарболла). Затем установите в качестве текущего каталога тот, который содержит hello-1.0 и наберите, например:

Это создаст архив, внутри которого есть каталог hello-1.0, который содержит hello.c и Makefile. Таков способ распространения пакетов.

C++-вариант пакета. Исходник будет тем же, его нужно будет назвать hello.cpp. Makefile будет таким:

Обратите внимание, что стандартное название переменной для флагов к компилятору C++ — это CXXFLAGS, а не CPPFLAGS. CPPFLAGS же — это название переменной для флагов к препроцессору C.

Теперь разберём, как устанавливать пакеты из сорцов (любые, программы и библиотеки). Независимо от системы сборки. Этот алгоритм будет пригоден в том числе для тарболла, который мы создали только что. Допустим, что пакет, который нужно собрать, тоже называется hello.

Первый шаг: скачать и зайти в папку с сорцами. Тут два варианта: скачиваем из системы контроля версий (я разберу для примера git) или скачиваем тарболл.

Первый вариант. git. Делаем clone:

Это создаст папку hello. Без номера версии, т. к. мы скачали из системы контроля версий. Делаем cd в созданную папку, т. е. cd hello .

Второй вариант. Тарболл. Скачиваем тарболл. Потом набираем команду, скажем, tar -xf hello-1.0.tar.xz . Это создаст папку, например, hello-1.0 . Обычно, если создатель пакета сделал всё правильно, имя папки будет содержать номер версии. Потом делаем cd в полученную папку, например, cd hello-1.0 .

Теперь нужно собрать. Будем считать для простоты, что мы не будем делать out of tree build (если автор пакета требует out of tree build, там обычно будут написаны инструкции, как это сделать). А значит, собирать мы будем в этой же папке, где сорцы. Т. е. в этой папке, в которую мы сейчас сделали cd.

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

Я дам здесь примерные инструкции, работающие в большинстве случаев. Точные инструкции вы увидите у автора проекта, там могут быть разные нюансы.

Обязательно указывайте prefix при сборке (что бы там не писал в инструкции автор). Если вы не укажите, то будет выбран дефолтный. Обычно это /usr/local, и это достаточно хороший выбор. А если нет? Что если автор пакета указал какой-то другой дефолтный префикс? Вы установите непонятно куда. В частности libqglviewer использует в качестве дефолтного префикса /usr, что совершенно неправильно (я отправил автору баг репорт). Итак, совершенно всегда указывайте префикс. Читайте инструкции, которые автор указывает на своём сайте и прикидывайте, куда впихнуть prefix.

Итак, какие могут быть системы сборки. Во-первых, может быть просто make. Такой вариант с голым make встречается редко. Один из немногих пакетов с «голым» make — bzip ( www.bzip.org ). В случае с нашим hello-1.0.tar.xz, который мы создали, у нас именно такой вариант.

Итак, собирать в случае голого make нужно так:

(Конкретно в случае с bzip на этапе сборки указывать PREFIX не надо. Но теоретически можно представить себе пакет, который захардкоживает PREFIX внутрь бинарника. Поэтому в общем случае PREFIX нужен.)

Следующий вариант — это autotools. В этом случае собираем так:

Читайте также:  Установка источников света для

Следующий вариант — cmake. Собираем так (обратите внимание на точку в конце команды cmake):

Откуда точка в конце? Дело в том, что cmake’у нужно передавать путь к сорцам. А поскольку у нас не out of tree build, мы собираем здесь же. Сорцы находятся там же, где находимся мы. Поэтому точка, т. е. текущий каталог.

В случае с autotools и cmake команда, генерирующая Makefile (т. е. ./configure или cmake) записывает prefix в конфиги к make, поэтому в команде make (и в команде make install, про которую речь пойдёт далее) указывать prefix уже не нужно.

Итак, собрали одним из этих способов. Что дальше? Теперь нужно установить.

В случае голого make это делается так:

Нужно будет указать тот же prefix, который вы указывали при сборке.

В случае autotools и cmake так:

В случае, если для записи в prefix вам нужен sudo, то вот эту команду для установки нужно будет набирать с sudo. Вообще, сборка всегда осуществляется с обычными правами, а вот установка осуществляется с теми правами, которые нужны, чтобы записать в prefix.

Окей, теперь посмотрим, что мы натворили. Допустим, что ставили мы не что-нибудь, а тот hello-1.0.tar.xz, который создавали до этого. Допустим также, что prefix, который мы указали, был /foo. Тогда в нашей системе появятся папки /foo, /foo/bin (если их не было до этого) и файл /foo/bin/hello. Что произошло? Указанная в командной строке при сборке переменная PREFIX=/foo переопределила заданную в Makefile PREFIX=/usr/local. В результате указанные в Makefile команды mkdir -p и install стали такими:

В результате бинарник положился в /foo/bin.

Теперь хочу ещё немного поговорить про префиксы. Какие префиксы вообще есть?

Префикс /. Вряд ли когда-нибудь вам придётся его выбирать. Он используется для программ, критичных для ранних стадий загрузки ОС (т. е. критичные элементы для загрузки находятся в /bin, /lib и т. д.) (впрочем, даже если вам нужно установить программу в /, её сперва устанавливают в /usr, т. е. собирают и устанавливают с префиксом /usr, а потом перемещают необходимое в / [т. е. перемещают из /usr/bin в /bin, скажем], во всяком случае именно так поступают авторы Linux From Scratch 7.10 с пакетом, скажем, bash).

Префикс /usr. Стандартный префикс, используемый обычно для программ, установленных через менеджер пакетов. То есть если вы установили программу через менеджер пакетов, она ведёт себя так, словно она собрана и установлена на вашей системе с префиксом /usr. Самому устанавливать пакеты с префиксом /usr нельзя.

Префикс /usr/local. Отличный префикс для установки туда программ самостоятельно. Хорош тем, что /usr/local/bin есть в дефолтном PATH (во всяком случае в дебиане). То есть сразу после установки программы вы сможете просто запускать программу по названию. Потому что бинарник лежит в /usr/local/bin, а /usr/local/bin есть в PATH. Плох тем, что там все программы лежат смешанно. Вот допустим, вы установили библиотеку foo, а потом библиотеку bar. Обе в этот prefix. Тогда дерево может выглядеть так (в совсем упрощённом виде):

Видите? Всё смешано. Нет единой папки, которая бы содержала «всё, связанное с foo» и другой папки, которая бы содержала «всё, связанное с bar». (Хотя это ваше дело, считать, что это действительно плохо или нет). Понятное дело, что такая же проблема присутствует при любой установке разных пакетов в один префикс. То есть префикс /usr страдает от того же: пакеты «размазаны» по системе (здесь уже речь идёт о пакетах, поставленных через менеджер пакетов, т. е. тех, которые, собственно, составляют систему). Собственно, это и есть одно из бросающихся отличий большинства UNIX-подобных систем от Windows. В Windows каждая программа находится в своей папке в Program Files. В большинстве UNIX-подобных систем она «размазана» по системе. (UPD от 2017-02-09: в Windows программы на самом деле тоже «размазаны», скажем, по реестру, просто это не так бросается в глаза.) Существуют дистибутивы GNU/Linux, «решающие» эту проблему, например, GoboLinux. Там каждый пакет в своём каталоге, как в Windows.

Префиксы вида /opt/XXX. Папку /opt предполагается использовать следующим образом: в ней нужно создавать подкаталоги, называть их названиями пакетов и использовать эти подкаталоги как префиксы. При таком подходе указанная выше проблема /usr/local (если считать её проблемой) исчезает. Каждый пакет будет установлен в свой каталог. Приведённый выше пример с foo и bar будет выглядеть так (я бы посоветовал в названии подкаталогов в /opt указывать ещё и номер версии):

Недостаток у такого решения тоже есть. Вам придётся самому добавлять все эти бесчисленные каталоги /opt/foo-1.0/bin (для каждого пакета) в PATH.

Префиксы, соответствующие домашним каталогам. Т. е., скажем, /home/user. Советую в случае, когда хочется поставить «только для себя», т. е. только для одного юзера. Или когда нет прав root. Возможно, ваши конфиги, поставляемые с ОС уже настроены таким образом, чтобы помещать

/bin в PATH при условии, что такой каталог есть. Так что PATH будет настроен как надо.

Каждый префикс может содержать в себе свои bin, sbin, lib, include и т. д.

Итак, что из этого выбрать? Если нужно поставить на всей системе, то я бы посоветовал /opt/XXX. Я сам так обычно ставлю.

Теперь о сборке, установке библиотеки и её использовании. Собирается и ставится библиотека так же, как и любой другой пакет, я это уже рассказывал выше. Так что перейдём сразу к использованию. Вот мы установили библиотеку в некий префикс, допустим, /foo. Теперь в /foo/include появились хедеры этой библиотеки, а в /foo/lib — бинарные файлы библиотеки (.so — динамическая библиотека, либо .a — статическая, либо и то, и то).

Допустим, нужно собрать некий файл a.c с этой библиотекой. Как это сделать?

Во-первых, вверху файла нужно написать #include, соответствующий подключаему хедеру. Ну а собирать нужно так:

Давайте разбираться. Для начала скажу, что I (большая английская и) и l (маленькая английская эль) — это две разные буквы. Не перепутайте их в приведённых командах.

Первая команда производит компиляцию, то есть создаёт a.o на основе a.c. Вторая — линковку, то есть окончательный бинарник на основании a.o.

В первой команде мы указали -I/foo/include. Это указание той папки, где нужно искать хедеры. Путь из этой опции соединится с файлом, указанным в #include. То есть если в командной строке указано -I/foo/include, а в файле написано #include , то получится /foo/include/foo.h, он-то и будет заинклуден.

Здесь опция -I/foo/include не осуществляет сама инклудивание. Она лишь указывает папку, где нужно искать, поэтому нужен ещё и #include. То есть нужен и -I/foo/include, и #include, одного из них недостаточно.

Линковка. -L/foo/lib — это указание папки, где нужно искать бинарные файлы библиотеки, т. е. файлы .so и .a. -lfoo — это указание на то, что нужно, собственно, прилинковать эту библиотеку к результирующему бинарнику. Имя библиотеки, указанное в опции -lfoo, соединится с папкой, указанной в -L/foo/lib и получится /foo/lib/libfoo (в начало названия файла вставляется слово «lib»), затем сюда прибавится .so (или .a) и опционально номер версии и получится /foo/lib/libfoo.so или, скажем, /foo/lib/libfoo.so.1. Это и будет тем именем .so-файла, который будет искаться.

Так же, как и при компиляции (a.o из a.c), нужны обе опции -L/foo/lib и -lfoo. -L/foo/lib указывает, где искать. А -lfoo даёт окончательную команду на прилинковку.

Вместо -lfoo можно прямо написать целиком путь до файла библиотеки, который нужно слинковать, например, /foo/lib/libfoo.so.1. Тогда опция -L/foo/lib не нужна. Получится так:

Библиотеку (будь то полный путь к библиотеке или опция вида -lfoo) нужно указывать после «своих» объектных файлов, в данном случае a.o. (Может, и не нужно, но на всякий случай лучше так делать.)

Можно соединить две наши команды в одну, тогда будет что-то такое:

В случае, если библиотека установлена с префиксом /usr (то есть просто установлена через менеджер пакетов), то опции -I и -L не нужны, считайте, что -I/usr/include и -L/usr/lib у вас как бы уже есть. То же, возможно, относится к /usr/local.

Если существует некая библиотека под названием foo, то она обычно запаковывается для дебиан в пакеты с названиями libfoo (или libfoo1, libfoo2) и libfoo-dev. libfoo содержит файлы .so, а libfoo-dev — хедеры. То есть хитрые разработчики дебиан умеют из одного пакета сделать несколько. На сборочных машинах дебиана пакет собирается и расфасовывается в несколько пакетов.

Если вы установите у себя на машине libfoo и libfoo-dev, то результат будет как если бы вы сами собрали пакет foo из исходных кодов с префиксом /usr. У вас на системе будут, скажем, файлы:

Напомню, что список файлов в данном пакете можно посмотреть по команде, скажем, dpkg -L libfoo . Ну а найти пакет по файлу с помощью dpkg -S /usr/include/foo.h .

источник