Системы управления пакетами в UNIX-подобных ОС (apt, rpm, pacman и др.)

Федеральное министерство по образованию РФ

 

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

 

Тверской государственный  технический университет

 

 

Кафедра ИНФОРМАЦИОННЫХ СИСТЕМ

 

 

 

 

Операционные  системы

 

 

 

 

РЕФЕРАТ НА ТЕМУ:

Системы управления пакетами в UNIX-подобных ОС (apt, rpm, pacman и др.)

 

 

 

 

 

Выполнил:

студент

Специальности

Ф.И.О.:

 

 

Преподаватель:   

 

 

 

2014г

 

 

 

 

1. Система управления пакетами.

2. UNIX и UNIX подобные ОС.

3 RPM

   3.1 Преимущества RPM над другими средствами управления и          

    установкой программного обеспечения

   3.2 Основные недостатки

4. dpkg

5. Pacman

6. Portage

   6.1 Дерево портежей

   6.2 Оверлеи

   6.3 live-пакеты

   6.4 Утилиты

7. Entropy.

8. PiSi

9. IPS(Image Packaging System)

10. apt

    

 

 

 

 

 

 

 

 

 

 

 

1. Система управления пакетами.

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

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

Как правило, система управления пакетами работает со множеством пакетов, хранящихся в специальном репозитории — хранилище, которое может располагаться как на локальных запоминающих устройствах (оптическом или жёстком диске), так и на удалённой машине (HTTP, FTP или rsync-сервере).

 

2. UNIX и UNIX подобные ОС.

Unix начала разрабатываться  в 1969 г. группой программистов,  работавших в американской фирме  Bell Laboratories. В начале 70-х годов для  удобства разработки Unix, а скорее  для того, чтобы большая часть  ОС была независима от архитектуры компьютера, Денисом Ритчи и Кеном Томпсоном был создан язык Си. На этом языке до сих пор пишутся основные части большинства ОС.

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

К середине 70-х Unix уже  был достаточно широко распространен. Следует учитывать, что в то время  персональных компьютеров (ПК) еще не было и под словами «широко распространен» имеются ввиду организации, владеющие большими компьютерами (по большей части это были университеты). Коллектив каждой организации, обзаведясь копией Unix (который распространялся бесплатно), старался его улучшить и расширить под свои нужды. Поэтому к концу десятилетия уже начинают появляться разновидности Unix. И даже появляется вариант коммерческого Unix'а.

В начале 80-х Unix был выбран в качестве системы, под которой  планировалось развивать сетевой  протокол TCP/IP, тем самым он получил хорошую поддержку для дальнейшего совершенствования и «прижился» на серверах.

С появлением коммерческих Unix'ов, полноценное развитие системы  приостановилось. Это было связано  с тем, что каждая фирма, продающая  свой Unix, запрещала распространять свои исходные коды. Другие программисты не могли воспользоваться уже сделанным и начинали реализовывать уже созданную кем-то функцию или программу сначала. Кроме того, каждая фирма вносила свои собственные изменения. В результате программы, написанные для одной системы, не могли работать в другой. Т. е. Unix'ы стали несовместимы между собой. Проблема совместимости сильно влияет на совместную работу.

Хотя вопросами стандартизации Unix в последствие стали заниматься, однако закрытость системы оказала на нее негативное влияние, и возможно привело к тому, что она упустила возможность развиваться в сторону персональных компьютеров.

UNIX-подобные операционные  системы (иногда сокр. как *nix) —  операционные системы, которые  образовались под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании Bell Labs или эмулирующие его возможности, коммерческие и запатентованные разработки, а также версии, основанные на исходном коде UNIX. Нет стандарта, определяющего термин, и допустимы различные точки зрения о том, считать ли определённый продукт UNIX-подобным или нет.

Деннис Ритчи, один из создателей UNIX, выразил своё мнение, что UNIX-подобные системы, такие как Linux, являются де-факто UNIX-системами.

 

Эрик Рэймонд предложил разделить UNIX-подобные системы на 3 типа:

• Генетический UNIX: Системы, исторически связанные с кодовой базой AT&T. Большинство, но не все коммерческие дистрибутивы UNIX-систем попадают под эту категорию. Так же, как и BSD-системы, которые являются результатами работы университета Беркли в поздних 1970-х и ранних 1980-х. В некоторых из этих систем отсутствует код AT&T, но до сих пор прослеживается происхождение от разработки AT&T.
• UNIX по товарному знаку, или бренду: эти системы, в основном коммерческого характера, были определены The Open Group как соответствующие Единой спецификации UNIX, и им разрешено носить имя UNIX. Большинство этих систем — коммерческие производные кодовой базы UNIX System V в той или иной форме (например, Amiga UNIX), хотя некоторые (например, z/OS компании IBM) заслужили торговую марку через слой совместимости с POSIX, не являясь по сути UNIX. Многие старые UNIX-системы не подходят под это определение.
• UNIX по функциональности: В целом, любая система, поведение которой примерно соответствует спецификации UNIX. К таким системам можно отнести Linux и Minix, которые ведут себя подобно UNIX-системе, но не имеют генетических связей с кодовой базой AT&T. Большинство свободных/открытых реализаций UNIX, являясь генетическим UNIX или нет, подпадают под ограниченное определение этой категории в связи с дороговизной сертификации The Open Group, которая стоит несколько тысяч долларов.
• Cygwin, не являясь операционной системой, предоставляет UNIX-подобную среду в Microsoft Windows; также существуют сервисы Microsoft Windows для UNIX.

 

 

Большинство производителей открытых UNIX-систем не добиваются сертификации UNIX для своего продукта даже в качестве компромата: стоимость сертификации считается недопустимой. Для таких  систем обычно используют термин «Freenix». Примером являются GNU, Linux, Minix, OpenSolaris, Plan 9 и BSD со своими потомками, такими как FreeBSD, NetBSD и OpenBSD.

Так же есть несколько Исследовательских систем:

• UNIX (разработана Bell Labs в 1970 году, идея Кена Томпсона)
• Mach (от разработчиков ядер ОС в CMU; см.: NeXTSTEP)
• xv6 (учебная ОС, сделанная в MIT)
• K42 (разрабатывается в IBM)
• MISS (первая отечественная UNIX-подобная операционная система)
• ДЕМОС (советский клон UNIX)
• ИНМОС (Инструментальная мобильная операционная система — разработана в СССР в 1985 году в ИНЭУМ Институт электронных управляющих машин, Головное КБ Минприбора).

И есть множество запатентованных UNIX-подобий, таких как: AIX, HP-UX, IRIX, Mac OS X, LynxOS, QNX, SCO OpenServer, Solaris, Tru64 UNIX, UnixWare, Xenix и VxWorks.

 

Наиболее известные  системы управления пакетами:

 

3 RPM

RPM (рекурсивный акроним  RPM Package Manager — RPM — менеджер пакетов;  ранее раскрывался как Red Hat Package Manager — менеджер пакетов Red Hat) обозначает две сущности: формат  пакетов программного обеспечения и программа, созданная для управления этими пакетами. Программа позволяет устанавливать, удалять и обновлять программное обеспечение. RPM является основным форматом пакетов в LSB.

Изначально разработанный  компанией Red Hat для Red Hat Linux, RPM стал использоваться во многих дистрибутивах Linux и был портирован на другие операционные системы: Novell NetWare (с версии 6.5 SP3), IBM AIX (с версии 5) и прочие.

Для хранения файлов в  формате RPM используется архивный контейнер cpio, с использованием сжатия утилитой gzip. В более поздних версиях может быть использован архиватор star и сжатие с помощью bzip2, LZMA или XZ. Начиная с версии RPM 5.0 возможно использование архиватора XAR.

База данных RPM ведётся  в каталоге /var/lib/rpm. Она состоит из одиночной базы данных (Packages), в которой хранится вся информация о пакетах, и множества маленьких баз (__db.001, __db.002 и т. д.), которые служат для индексации и содержат в себе сведения о том, какие файлы менялись и создавались при установке и удалении пакетов.

Если база данных несколько  испортится (что может произойти, если процесс установки или удаления был «убит» или закончилось место  на разделе), то её можно восстановить, введя команду rpm --rebuilddb.

Если база была уничтожена — рекомендуется достать копию из заранее сделанного бэкапа или восстановить при помощи rpm -ivh --justdb по списку пакетов, заранее полученному командой rpm -qa | sort. Возможны полуэвристические методы восстановления базы по списку файлов в пакетах репозитория, из которого была установлена система, но лучше до этого не доводить.

Каждый пакет RPM имеет  название, которое состоит из нескольких частей:

• Название программы
• Версия программы
• Номер релиза (количество раз пересборки программы одной и той же версии). Также часто используется для обозначения дистрибутива, под который собран этот пакет, например mdv (Mandriva Linux) или fc4 (Fedora Core 4).
• Архитектура, под которую собран пакет (i386, ppc и т. д.)

Собранный пакет обычно имеет такой формат названия:

<название>-<версия>-<релиз>.<архитектура>.rpm

Например:

nano-0.98-2.i386.rpm

Иногда в пакет входят исходные коды. Такие пакеты не содержат информации об архитектуре, она заменяется на src.

Например:

libgnomeuimm2.0-2.0.0-3.src.rpm

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

3.1 Преимущества RPM над другими средствами управления и установкой программного обеспечения:

• Лёгкость удаления и обновления программ
• Популярность: очень многие программы собираются именно в RPM, поэтому нет необходимости собирать программу из исходных кодов
• «Неинтерактивная установка»: легко автоматизировать процесс установки/обновления/удаления
• Проверка целостности пакетов с помощью контрольных сумм и GPG-подписей
• DeltaRPM, аналог патча, позволяющий обновить установленное программное обеспечение с минимальной затратой трафика
• Возможность аккумуляции опыта сборщиков в spec-файле
• Относительная компактность spec-файлов за счёт использования макросов

3.2 Основные недостатки:

• Макропакеты между дистрибутивами могут существенно различаться
• Раздробленность и несовместимость различных версий. Так, существуют проекты по разработке RPM 4 (rpm.org), RPM5 (rpm5.org), а также большое количество патчей на RPM в дистрибутивах. В частности, это приводит к:
• Несовместимости spec-файлов между дистрибутивами (spec-файл ALT Linux чаще всего невозможно собрать на Red Hat или SuSE без значительных исправлений)
• Несовместимости названий пакетных зависимостей при попытке установить пакет от другого дистрибутива (например, зависимости в RPM сборки Connectiva создаются по другим правилам, нежели в Mandriva).

Для создания пакета нужен spec-файл. Это обычный текстовой файл, имеет суффикс .spec и содержит в себе название пакета, версию, номер релиза, инструкции по сборке и установке пакета и список изменений. При наличии spec-файла пакет создаётся командой rpmbuild.

 

4. dpkg

dpkg — это программное обеспечение,  являющееся основой системы управления пакетами в Debian и ряде других операционных систем, основанных на Debian, например Ubuntu. dpkg используется для установки, удаления, и получения информации о .deb пакетах.

dpkg является довольно  низкоуровневой утилитой. Существуют более высокоуровневые утилиты, например APT, которые могут загружать пакеты из сетевого репозитория и отслеживать зависимости между пакетами. Конечным пользователям следует использовать утилиты с более дружественным интерфейсом, такие как Aptitude или Synaptic, предоставляющие лёгкий способ просмотра списка пакетов, их описания и зависимостей.

dpkg изначально был  создан Мэттом Уэлшом, Карлом  Стритером и Яном Мёрдоком. Изначально dpkg был написан на Perl, но позже основная часть была переписана на Си Яном Джексоном в 1993. Название «dpkg» — это сокращение от «Debian package».

Утилиту можно использовать для установки пакета .deb командой:

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

Где имя_пакета.deb — это имя файла пакета (пакеты в Debian имеют расширение .deb). Запускать dpkg необходимо с правами суперпользователя (root).

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

dpkg -l [маска]

Для удаления установленного пакета:

dpkg -r имя_пакета

Пакет dpkg-dev содержит серию инструментов, которые вызываются для создания пакета. Вот они:

• dpkg-source архивирует и распаковывает исходные файлы пакета Debian.
• dpkg-deb архивирует и распаковывает двоичные пакеты.
• dpkg-gencontrol читает информацию из распакованного пакета Debian о дереве исходных файлов и генерирует двоичный пакет.
• dpkg-shlibdeps прослеживает зависимости пакета.
• dpkg-genchanges читает информацию из распакованного пакета Debian о дереве исходных файлов. которые запущены единожды создают контрольный файл (.changes).
• dpkg-buildpackage — это контрольный скрипт, который может быть использован для автоматического создания пакета.
• dpkg-distaddfile добавляет файл в файлы Debian.
• dpkg-parsechangelog читает информацию из файла с изменениями распакованного пакета Debian и создаёт удобный файл с этими изменениями для просмотра его пользователем.

 

5. Pacman

Pacman является официальным  менеджером пакетов для дистрибутива Arch Linux. Pacman был разработан создателем Arch Linux Джаддом Вине.

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