Содержание


Инструменты ОС Linux для разработчиков приложений для ОС Windows. Часть 10. Поставка и установка программного обеспечения

Comments

В ОС Linux из-за используемой GPL лицензии существуют несколько способов инсталляции нового программного обеспечения, и эти способы разительно отличаются от имеющихся в ОС Windows.

Способы инсталляции ПО

Самым простым способом является бинарная установка – способ, нечасто встречающийся в Linux, и напоминающий процесс инсталляции ПО в ОС Windows, когда достаточно просто запустить программу или сценарий, результатом которых и станет установленное ПО. Так происходит установка некоторых видов закрытого программного обеспечения.

Установка программы из репозитария с помощью пакетной системы используемого дистрибутива Linux. В этом случае установка выполняется с помощью менеджера пакетной системы, который использует установочные пакеты в специфическом формате дистрибутива. Поиск файлов может происходить как локально, так и на разнообразных ресурсах в глобальной сети (в последнее время применяется именно такой подход). Преимущества пакетной установки заключаются в её простоте и в том, что при установке автоматически разрешаются зависимости между пакетами. Так, если пакет зависит от других, ещё не установленных пакетов, то менеджер пакетной системы либо установит всю иерархию пакетов, либо прервёт инсталляцию до тех пор, пока зависимости не будут разрешены каким-нибудь другим способом.

Установка из исходных кодов - это традиционный для ОС Linux способ установки программных пакетов, который появился самым первым. За время существования ОС Linux появилось много разновидностей этого процесса, но общим у всех них остаётся одно: программные средства предоставляются в исходном коде (это требование лицензии GPL) и компилируются в целевой системе, после чего устанавливаются в соответствии со специфическими требованиями пакета. Преимущества этого подхода заключаются в полном контроле установленного программного обеспечения системы, всегда самых свежих версиях и отсутствии любых подозрений на вирусы и другие неприятности. Но этот способ требует высокой квалификации и даже сообразительности, так как неправильный подход к разрешению зависимостей между пакетами и версиями может привести к получению неработоспособного ПО.

Бинарная установка

Бинарная установка, то есть установка уже готовых исполняемых файлов или выполнение исполняемых инсталляционных программ (сценариев), крайне редко встречается в открытых POSIX системах:

Старейший способ распространения бинарных пакетов заключался в "разархивировании от корня", т.е. нужно было просто разархивировать tar-архив в корень файловой системы, при этом файлы из архива автоматически были бы помещены в соответствующие каталоги файловой иерархии. В ОС Linux этот способ уже почти не используется, но его всё еще можно встретить в других POSIX системах.

Такой способ бинарной установки можно наблюдать на примере популярного пакета Oracle Solaris Studio, когда необходимо загрузить архив вида SolarisStudio12.2-linux-x86-tar-ML.tar.bz2 и развернуть содержащийся в нём каталог solstudio12.2 в желаемое место установки (для Linux это обычно каталог /opt/oracle, который ещё нужно создать), чтобы получить подобный результат:

$ pwd
/opt/oracle/solstudio12.2
$ ls
bin  examples  include  LEGAL  lib  man  netbeans  prod  READMEs
$ du -hs
884M	.

Также потребуется прописать пути к исполняемым файлам нового пакета в переменных окружения:

PATH=$PATH:/opt/oracle/solstudio12.2/bin ; export PATH
MANPATH=$MANPATH :/opt/oracle/solstudio12.2/man; export $MANPATH

После чего уже можно запускать установленную интегрированную среду разработки:

$ solstudio &

Другой способ бинарной установки до последнего времени использовался для Java инструментов JDK и JRE от компании Sun (теперь от Oracle). Например, инсталляционный файл: jre-6u18-linux-i586.bin - это сценарий оболочки до смещения примерно 0x3528, за которым следует большой фрагмент исполняемого кода. Точно так же распространяется свободное программное обеспечение NVIDIA: закрытые версии драйверов для видеокарт компании - файл NVIDIA-Linux-x86-280.13.run, или набор средств разработки CUDA – файл cudatoolkit_4.0.17_linux_32_fedora13.run. Всё это свободное, но не открытое программное обеспечение.

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

$ chmod a+x jre-6u18-linux-i586.bin
$ ./jre-6u18-linux-i586.bin
...

Или указать командному интерпретатору на исполняемость переданного файла другими способами, например:

$ sh jre-6u18-linux-i586.bin
...
$ bash jre-6u18-linux-i586.bin
...

Бинарный способ установки не имеет, с точки зрения потребителя, каких-либо преимуществ, за исключением, возможно, исключительной простоты. Но именно в таком формате распространяются многие популярные программы, например: Sun/Oracle JDK/JRE, IDE NetBeans, IDE Solaris Studio, Skype и д.р.

Необходимо учитывать ещё одну особенность бинарной инсталляции ПО в ОС Linux. Если бинарный программный пакет использует или строит модуль ядра Linux (часто так делают драйверы), то такой установленный программный пакет перестанет функционировать сразу, как только вы обновите версию ядра Linux, даже если изменение заключалось в переименовании или выполнялось из репозитария версий самого дистрибутива. Эта проблема связана с контролем соответствия версий ядра и его модулей, и, в принципе, её можно обойти, но это достаточно трудно и не совсем легально, а кроме того может привести к неконтролируемым последствиям.

Пакетная установка

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

  • формат пакета .deb и менеджер пакетов apt в дистрибутивах Debian и Ubuntu;
  • пакетный формат .rpm и менеджеры rpm и yum в дистрибутивах ReaHat, Fedora, CentOS, Mandriva.

Так как принципы функционирования этих пакетных систем во многом совпадают, то далее будет рассматриваться только одна линия: rpm и yum.

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

Логика пакетной системы состоит в том, что файл инсталляционного пакета содержит не только сами устанавливаемые файлы, но и требования по зависимостям данного пакета от ранее установленных пакетов. Таким образом, пакет может быть установлен, только если удовлетворены все требуемые для него зависимости. То же самое относится и к процессу удаления пакетов: удалить можно только такой пакет, от которого не зависит ни один из установленных в системе пакетов. Для поддержания целостности установленной системы программного обеспечения, менеджер пакетов ведёт в той или иной форме базу данных пакетной системы.

Пакетная система rpm и менеджер yum

Пакетная система rpm обслуживается набором утилит пакетного менеджера:

$ ls /usr/bin/rpm*
/usr/bin/rpm2cpio  /usr/bin/rpmbuild  /usr/bin/rpmdb  /usr/bin/rpmgraph
/usr/bin/rpmquery  /usr/bin/rpmsign  /usr/bin/rpmverify
$ rpm –version
RPM версия 4.4.2

Позже, над подсистемой пакетного менеджера rpm, и под явным влиянием пакетной системы apt Debian, был надстроен мета-менеджер yum. Если менеджер rpm используется для установки пакетов из файлов пакетов вида <имя>.rpm, то мета-менеджер yum используется для поиска файла пакета в известных сетевых репозитариях, загрузки файла и его установки в систему. Конечная фаза установки происходит при участии менеджера rpm, но это скрыто от пользователя. Размещение пакетных файлов на локальном диске на самом деле является частным случаем сетевого размещения, поэтому yum с таким же успехом может использоваться и для локальной инсталляции, полностью заменяя при этом менеджер rpm.

Ниже показано, как выполняется проверка наличия (поиск) требуемых пакетов в сетевых репозитариях:

# yum list available djvu*
...
Доступные пакеты
djvulibre.i686                  3.5.21-3.fc12                        fedora
djvulibre-devel.i686            3.5.21-3.fc12                        fedora
djvulibre-mozplugin.i686        3.5.21-3.fc12                        fedora

А так выполняется установка найденного пакета (или группы пакетов по маске, как в данном примере) из репозитария:

# yum install djvu*
...
New leaves:
  djvulibre-devel.i686
  djvulibre-mozplugin.i686

Список сетевых репозитариев, известных мета-менеджеру yum, может настраиваться и хранится в виде файлов в каталоге /etc/yum.repos.d. Подробное описание процесса конфигурирования yum можно найти в сопутствующей документации.

Вот как производится установка пакета из локального файла (*.rpm):

# yum --nogpgcheck localinstall djvulibre-3.5.18-1.fc7.i386.rpm
...

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

# rpm -i djvulibre-3.5.18-1.fc7.i386.rpm

Также отметим, что инсталляцию *.rpm лучше выполнять с помощью команды yum, как показано выше, потому что (хотя это и не доказано) при установке через yum установленный пакет учитывается в единой базе данных yum, и это сказывается при учёте зависимостей в ходе установки и удаления других пакетов.

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

В некоторых случаях ПО можно получить или загрузить из сети в виде файлов пакетов в формате *.src.rpm. Это пакеты исходных кодов, собранные той же утилитой для создания rpm-пакетов (rpmbuild), но в результате установки такого пакета можно получить только исходный код приложения, который ещё нужно будет компилировать. Вопросы компиляции будут обсуждаться в следующей статье. Но если попытаться установить *.src.rpm с помощью yum, то может возникнуть следующая проблема:

# yum localinstall esvn-0.6.12-1.src.rpm
...
Проверка esvn-0.6.12-1.src.rpm: esvn-0.6.12-1.src
Невозможно добавить пакет esvn-0.6.12-1.src.rpm в список действий. 
Несовместимая архитектура: src
Выполнять нечего

В таком случае необходимо воспользоваться командой rpm, которая имеет множество параметров, но все они описаны в справочниках: rpm --help, man rpm, и т.д.

# rpm -i -vvv esvn-0.6.12-1.src.rpm
D: ============== esvn-0.6.12-1.src.rpm
D: Expected size:      1930964 = lead(96)+sigs(180)+pad(4)+data(1930684)
D:   Actual size:      1930964
...
D: ========== Directories not explicitly included in package:
D:          0 /root/rpmbuild/SOURCES/
D:          1 /root/rpmbuild/SPECS/
D: ==========                            
...

После выполнения этой команды в домашнем каталоге текущего пользователя $HOME (в показанном примере команда выполнялась от имени root) будут созданы следующие каталоги:

# ls -R /root/rpmbuild
/root/rpmbuild:
SOURCES  SPECS
/root/rpmbuild/SOURCES:
esvn-0.6.12-1.tar.gz
/root/rpmbuild/SPECS:
esvn.spec

С полученным исходным кодом уже можно работать, как и с исходным кодом любого другого происхождения.

Создание собственного инсталляционного пакета

Для построения собственных инсталляционных пакетов для распространения ПО используется утилита rpmbuild. Мы не будем подробно рассматривать создание подобных пакетов, так как это выходит за рамки данной статьи, и ограничимся кратким обзором:

  1. создаётся текстовый файл сценария, с расширением *.spec, например, для уже упоминаемого пакета esvn-0.6.12-1.src.rpm это esvn.spec;
  2. текст сценария редактируется, как показано в листинге 1, и имеет фиксированную структуру секций, состоящую из целей и макросов, начинаемых в записи с символа %:
    Листинг 1. Сценарий для создания исполняемого пакета
    Summary: Graphical frontend for subversion
    Name: esvn
    Version: 0.6.12
    Release: 1
    License: GPL
    ...
    Vendor: eSvn
    BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
    ...
    %build
    %{__make} %{?_smp_mflags}
    %install
    %{__rm} -rf %{buildroot}
    %{__install} -Dp -m0755 esvn %{buildroot}%{_bindir}/esvn
    ...
  3. имя файла этого сценария создания пакета передаётся в качестве параметра утилите rpmbuild.

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

Инсталляция из исходного кода

Инсталляция из исходных текстов программного обеспечения — это основной способ, используемый программистами для обновления ПО. Кроме того, изначально это был первый и единственный способ распространения программного обеспечения для ОС Linux. Несомненными преимуществами такого подхода являются максимальная гибкость и то, что с его помощью можно получить самую свежую реализацию необходимых программ или библиотек. Но и у этого способа есть свои недостатки:

  1. Инсталляция ПО путём компиляции исходных текстов и их последующей установки требуют, как минимум, некоторых навыков программиста (для компиляции) и некоторых навыков администратора (для установки).
  2. Также необходимо учитывать, что при установке из исходных кодов производится только минимальный контроль (и это в лучшем случае, на этапе ./configure) зависимостей, требований наличия других пакетов и библиотек, без которых устанавливаемая программа останется неработоспособной;
  3. Кроме того, при обновлении существующего приложения на его новую версию может возникнуть конфликт версий, например, установка 2-х версий пакета, но с разными базовыми каталогами инсталляции (параметр --prefix при ./configure) может привести к абсолютно непредсказуемым последствиям;
  4. Ещё одной проблемой могут стать конфликты инсталляций из исходных кодов, инсталляций с помощью пакетной системы и бинарных инсталляций. Подобной ситуаций никак не избежать, потому, как даже при желании пользоваться только установкой из исходных кодов, огромное число начальных пакетов дистрибутива (при начальной CD-инсталляции) ставится пакетной системой и также существует ряд приложений (JDK, Skype, ...) которые можно установить только в виде бинарных пакетов.

В силу всех этих ограничений, установку из исходных текстов можно отнести скорее к "искусству", чем к рутинной процедуре. Но прежде, чем приступить к инсталляции пакета с исходным кодом, потребуется провести некоторую подготовку. Основная масса пакетов с исходным кодом поступает в виде архивов самых разных форматов, чаще это *.tgz (*.tar.gz), *.tar.bz2 или *.tar.Z. Архив помещается в каталог для распаковки, например, $HOME или /usr/src, и разворачивается в каталог (дерево) исходных кодов:

$ tar -zxvf xxx.tar.gz
...

Или (если это *.bz2):

$ tar -jxvf xxx.tar.gz
...

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

Заключение

Но перед тем как переходить к компиляции и установки пакета, необходимо сначала по внешним признакам поставки определить тип пакета, чтобы понять, какие инструменты потребуются для работы с ним. Эту информацию можно найти в README-файле в каталоге пакета, и можно выделить несколько наиболее часто встречающихся вариантов:

  • пакеты для непосредственной сборки;
  • пакеты, подготовленные средствами Autoconf/Automake (сегодня этот способ встречается чаще всего);
  • пакеты, подготовленные Cmake;

В следующей статье мы опишем, как выполнять сборку пакета из исходных кодов для всех трёх вариантов.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=969089
ArticleTitle=Инструменты ОС Linux для разработчиков приложений для ОС Windows. Часть 10. Поставка и установка программного обеспечения
publish-date=04212014