Стандарты пакетов Manjaro
Представленные PKGBUILD ни при каких обстоятельствах не должны собирать приложения, уже находящиеся в официальных бинарных репозиториях. Исключением из этого строгого правила могут быть только пакеты с включенными дополнительными функциями и/или патчами по сравнению с официальными. В этом случае массив pkgname должен быть другим.
При создании пакетов для Manjaro Linux, придерживайтесь руководства по созданию пакетов, приведенного ниже, особенно если вы собираетесь внести свой вклад в новый пакет для Manjaro Linux. Вам также следует ознакомиться с PKGBUILD и makepkg manpages.
Прототип PKGBUILD
# Maintainer: Иван Иванов pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=() url="" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #автозаполнение с помощью updpkgsums build() < cd $pkgname-$pkgver ./configure --prefix=/usr make >package() < cd $pkgname-$pkgver make DESTDIR="$pkgdir/" install >
Другие прототипы можно найти в /usr/share/pacman из пакетов pacman и abs.
Этикет упаковки
- Пакеты никогда не должны устанавливаться в /usr/local
- Не вводите новые переменные в PKGBUILD в скрипты сборки, если только пакет не может быть собран без этого, так как они могут конфликтовать с переменными, используемыми в самом makepkg. Если новая переменная в самом деле необходима, предварите её имя нижним подчеркиванием ( _ ), напр.
_customvariable=
AUR не может определить использование пользовательских переменных и поэтому не может использовать их в подстановках. Чаще всего это можно увидеть в исходном массиве, например.
http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2
optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')
Именование пакетов
- Имена пакетов должны состоять только из буквенно-цифровых символов; все буквы должны быть строчными.
- Имена пакетов НЕ должны иметь суффикс с номером версии основного выпуска upstream (например, нам не нужен libfoo2, если upstream называет его libfoo v2.3.4) в случае, если ожидается, что библиотека и ее зависимости будут использовать самую последнюю версию библиотеки с каждым соответствующим выпуском upstream. Однако не для всех программ или зависимостей можно ожидать подобное. В прошлом это было верно для наборов инструментов виджетов, таких как GTK и Qt. Программное обеспечение, зависящее от таких наборов инструментов, как правило не может быть тривиально перенесено на новую основную версию. Поэтому в случаях, когда программы не могут тривиально продолжать развиваться вместе со своими зависимостями, имена пакетов должны содержать суффикс основной версии (например, gtk2, gtk3, qt4, qt5). Для случаев, когда большинство зависимостей могут продолжать распространяться вместе с новейшим релизом, но некоторые не могут (например, закрытый исходный код, требующий libpng12 или аналогичный), устаревшая версия пакета может называться libfoo1, а текущая версия — просто libfoo.
- Версии пакетов должны быть такими же, как версия, выпущенная автором. Версии могут включать буквы, если это необходимо (например, версия nmap — 2.54BETA32). Теги версий не должны включать дефисы!. Только буквы, цифры и точки.
- Релизы пакетов — это специфические для Manjaro Linux пакеты. Они позволяют пользователям различать более новые и более старые сборки пакетов. Когда новая версия пакета выпускается впервые, счетчик релизов начинается с 1. Затем, по мере внесения исправлений и оптимизаций, пакет будет перевыпущен для публики Manjaro Linux и номер релиза будет увеличиваться. Когда выходит новая версия, счетчик релизов обнуляется до 1. Теги релизов пакетов следуют тем же ограничениям именования, что и теги версий.
- Конфигурационные файлы должны размещаться в каталоге /etc . Если существует более одного файла конфигурации, обычно принято использовать подкаталог, чтобы сохранить область /etc как можно более чистой. Используйте /etc// , где — имя пакета (или подходящую альтернативу, например, apache использует /etc/httpd/ ).
- Файлы пакетов должны следовать этим общим рекомендациям по каталогам:
- Пакеты не должны содержать ни одного из следующих каталогов:
- /dev
- /home
- /srv
- /media
- /mnt
- /proc
- /root
- /selinux
- /sys
- /tmp
- /var/tmp
- /run
Обязанности Makepkg
Когда makepkg используется для сборки пакета, он автоматически выполняет следующие действия:
- Проверяет, установлены ли пакеты dependencies и makedepends.
- Загружает исходные файлы с серверов
- Проверяет целостность исходных файлов
- Распаковывает исходные файлы
- Применяет все необходимые патчи.
- Собирает программное обеспечение и устанавливает его в поддельный корень
- Удаляет символы из двоичных файлов
- Удаляет отладочные символы из библиотек
- Сжимает руководство и/или информационные страницы
- Генерирует мета-файл пакета, который включается в каждый пакет
- Сжимает поддельный корень в файл пакета
- Сохраняет файл пакета в настроенном каталоге назначения ( cwd по умолчанию)
Архитектуры
Массив arch должен содержать ‘i686’ и/или ‘x86_64’ в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать ‘any’ для независимых от архитектуры пакетов.
Массив license внедряется в официальные репозитории, и его следует использовать и в ваших пакетах. Используйте его следующим образом:
- В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL. Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=(‘GPL’).
- Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
- Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это — использовать:
install -D -m644 LICENSE "$/usr/share/licenses/$/LICENSE"
- (L)GPL — (L)GPLv2 или любая поздняя версия
- (L)GPL2 — только (L)GPL2y
- (L)GPL3 — (L)GPL3 или любая поздняя версия
Предоставление пакетов в AUR
Перед отправкой пакетов в AUR обратите внимание на следующее:
- Представленные PKGBUILD НЕ ДОЛЖНЫ собирать приложения, уже находящиеся в любом из официальных бинарных репозиториев, ни при каких обстоятельствах. Исключением из этого строгого правила могут быть только пакеты, в которых включены дополнительные функции и/или исправления по сравнению с официальными. В этом случае массив pkgname должен быть другим, чтобы выразить эту разницу. Например. Пакет GNU screen PKGBUILD, содержащий патч sidebar, может быть назван screen-sidebar и т.д. Кроме того, массив provides=(‘screen’) Массив PKGBUILD следует использовать чтобы избежать конфликтов с официальным пакетом.
- Для обеспечения безопасности пакетов, отправляемых в AUR, пожалуйста, убедитесь, что вы правильно заполнили поле md5sum . md5sum можно сгенерировать с помощью команды updpkgsums .
- Пожалуйста, добавьте строку комментария к верхней части файла PKGBUILD , который следует этому формату. Не забудьте замаскировать свой e-mail для защиты от спама:
# Maintainer: Ваше Имя
Если вы берете на себя роль сопровождающего для существующего PKGBUILD, добавьте свое имя в верхнюю часть, как описано выше, и измените имя предыдущего сопровождающего(их) на Contributor:
# Maintainer: Ваше Имя # Contributor: Предыдущее Имя
foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf
Создание пакетов Manjaro
Эта статья призвана помочь пользователям в создании собственных пакетов с помощью оптимизированных инструментов разработчика Manjaro, а также для отправки в бинарные репозитории Manjaro. В ней рассказывается о создании PKGBUILD, файла описания сборки пакета, который используется makepkg для создания бинарного пакета из исходного кода. Если у вас уже есть PKGBUILD (см. makepkg). Инструкции относительно существующих правил и способов улучшения качества пакетов смотрите в Стандарт пакетизации Manjaro.
Обзор
Пакеты в Manjaro Linux собираются с помощью утилиты makepkg и информации, хранящейся в файле PKGBUILD. Когда запускается makepkg , она ищет PKGBUILD в текущем каталоге и следует инструкциям в нем чтобы скомпилировать или иным образом получить необходимые файлы для упаковки в файл пакета ( pkgname.pkg.tar.xz ). Полученный пакет содержит двоичные файлы и инструкции по установке; легко устанавливаемый с помощью pacman.
Пакет Manjaro — это не более чем tar-архив, или «tarball», сжатый с помощью xz, содержащий следующие файлы, созданные makepkg:
- Бинарные файлы для установки.
- .PKGINFO : содержит все метаданные, необходимые pacman для работы с пакетами, зависимостями и т.д.
- .MTREE : содержит хэши и временные метки файлов, включаемые в локальную базу данных, чтобы pacman мог проверить целостность пакета.
- .INSTALL : необязательный файл, используемый для выполнения команд после этапа установки/обновления/удаления. (Этот файл присутствует, только если он указан в PKGBUILD ).
- .Changelog : необязательный файл, хранящийся у сопровождающего пакета и документирующий изменения пакета. (Он присутствует не во всех пакетах).
Подготовка
Необходимое программное обеспечение
Сначала убедитесь, что необходимые инструменты установлены. Группы пакетов base-devel должно быть достаточно; она включает make и дополнительные инструменты, необходимые для компиляции из исходного кода.
# pacman -S base-devel
Одним из ключевых инструментов для сборки пакетов является makepkg (доступный в pacman), который делает следующее:
- Проверяет, установлены ли зависимости пакета.
- Скачивает исходный файл(ы) с указанного сервера(ов).
- Распаковывает исходный файл(ы).
- Компилирует программу и устанавливает ее в окружении fakeroot.
- Удаляет символы из двоичных файлов и библиотек.
- Генерирует метафайл пакета, включаемый в каждый пакет.
- Сжимает окружение fakeroot в файл пакета.
- Сохраняет файл пакета в настроенном каталоге назначения, который по умолчанию является текущим рабочим каталогом.
Загрузка и тестирование установки
Загрузите исходный tarball программы, которую вы хотите упаковать, распакуйте его и следуйте указаниям автора для установки программы. Запишите все команды и/или шаги, необходимые для компиляции и установки. Вы будете повторять эти же команды в файле PKGBUILD.
Большинство авторов программного обеспечения придерживаются трехэтапного цикла сборки:
./configure make make install
Это подходящее время, чтобы убедиться, что программа работает правильно.
Создание PKGBUILD
Когда вы запускаете makepkg , он будет искать файл PKGBUILD в текущем рабочем каталоге. Если файл PKGBUILD найден — он загрузит исходный код программы и скомпилирует его в соответствии с инструкциями, указанными в файле PKGBUILD . Инструкции должны быть полностью интерпретируемы оболочкой [[1]]. После успешного завершения, полученные двоичные файлы и метаданные пакета (версия пакета и зависимости) упаковываются в пакетный файл pkgname.pkg.tar.xz , который может быть установлен с помощью pacman -U .
Чтобы начать работу с новым пакетом, сначала нужно создать пустой рабочий каталог (предпочтительно ~/abs/pkgname ), перейти в этот каталог и создать файл PKGBUILD . Вы можете либо скопировать прототип PKGBUILD /usr/share/pacman/PKGBUILD.proto в свой рабочий каталог, либо скопировать PKGBUILD из аналогичного пакета. Последний вариант может быть полезен, если вам нужно изменить всего несколько параметров.
Определение переменных PKGBUILD
Примеры PKGBUILD находятся в /usr/share/pacman/ . Объяснение возможных переменных PKGBUILD можно найти в статье PKGBUILD.
makepkg определяет три переменные, используемые в процессе сборки и установки:
startdir Содержит абсолютный путь к директории, в которой находится файл PKGBUILD . Раньше эта переменная использовалась в сочетании с постфиксами /src или /pkg , но современным методом является использование переменных srcdir и pkgdir . $startdir/src не гарантированно совпадает с $srcdir , и то же самое для $pkgdir . Использование этой переменной является устаревшим и настоятельно не рекомендуется. srcdir Указывает на каталог, куда makepkg извлекает или копирует все исходные файлы. pkgdir Указывает на каталог, где makepkg собирает установленный пакет, который становится корневым каталогом вашего собранного пакета.
Все они содержат абсолютные пути — это означает, что вам не нужно беспокоиться о рабочем каталоге, если вы правильно используете эти переменные.
Note makepkg, и, следовательно, функции build() и package() , предназначены для неинтерактивного использования. Интерактивные утилиты или скрипты, вызываемые в этих функциях, могут сломать makepkg, особенно если он вызывается с включенным протоколированием сборки ( -l ) (см. FS13214.)
Note Помимо текущего сопровождающего (Maintainer) пакета, могут быть предыдущие, перечисленные выше как Contributors
Функции PKGBUILD
Существует 5 функций, перечисленных здесь в порядке их выполнения, если все они существуют. Если одна из них отсутствует — она просто пропускается.
Note Это не относится к функции package() , поскольку она требуется в каждом PKGBUILD
Функция pkgver()
Начиная с pacman 4.1, вы можете обновлять переменную pkgver во время makepkg. pkgver() запускается сразу после получения и извлечения исходных текстов.
Это особенно полезно, если вы создание пакетов git/svn/hg/итд, где процесс сборки может оставаться неизменным, но исходники могут обновляться каждый день, даже каждый час. Старый способ сделать это состоял в том, чтобы поместить дату в поле pkgver, которое, если программа не была обновлена, makepkg все равно пересобирал ее, думая, что версия изменилась. Некоторые полезные команды для этого — git describe , hg identify -ni и т.д. Пожалуйста, проверьте их перед отправкой PKGBUILD, так как сбой в функции pkgver() может остановить сборку на корню.
Note pkgver не может содержать пробелы или дефисы ( — ). Обычно для исправления этого используется sed
Функция prepare()
В Pacman 4.1 появилась функция prepare() . В этой функции выполняются команды, используемые для подготовки исходных текстов к сборке, например, патчинг. Эта функция выполняется перед функцией сборки и после извлечения пакета. Если извлечение пропущено ( makepkg -e ), то prepare() не выполняется.
Note (Из man PKGBUILD ) Функция выполняется в режиме bash -e , то есть любая команда, выполнившаяся с ненулевым статусом, вызовет выход функции.
Функция build()
Теперь вам нужно реализовать функцию build() в файле PKGBUILD . Эта функция использует обычные команды оболочки в синтаксисе [[2]] для автоматической компиляции программного обеспечения и создания каталога pkg для установки программного обеспечения. Это позволяет makepkg упаковывать файлы без необходимости рыться в файловой системе.
Первым шагом в функции build() является переход в каталог, созданный в результате распаковки исходного tarball. makepkg изменит текущий каталог на srcdir перед выполнением build() , поэтому в большинстве случаев первая команда будет выглядеть следующим образом:
cd "$pkgname-$pkgver"
Файл /usr/share/pacman/PKGBUILD.proto предлагает сделать
cd "$srcdir/$pkgname-$pkgver"
вместо этого. Опять же, поскольку $srcdir является абсолютным путем, это не имеет никакого значения.
Теперь вам нужно перечислить те же команды, которые вы использовали при ручной компиляции программы. Функция build() по сути автоматизирует все, что вы делали вручную, и компилирует программу в среде сборки fakeroot. Если программное обеспечение, которое вы упаковываете, использует сценарий configure, хорошей практикой будет использование —prefix=/usr при сборке пакетов для pacman. Многие программы устанавливают файлы относительно каталога /usr/local , что следует делать только при ручной сборке из исходников. Все пакеты Arch Linux должны использовать каталог /usr . Как видно из файла /usr/share/pacman/PKGBUILD.proto , следующие две строки обычно выглядят следующим образом:
./configure --prefix=/usr make
Note Если вашей программе не нужно ничего собирать, НЕ используйте функцию build() . Функция build() в таком случае не требуется, но требуется функция package() .
Функция check()
Место для вызовов make check и подобных процедур тестирования. Настоятельно рекомендуется иметь check() , так как это помогает убедиться, что программное обеспечение было собрано правильно и отлично работает со своими зависимостями.
Пользователи, которым это не нужно (и иногда сопровождающие, которые не могут исправить пакет, чтобы это прошло), могут отключить его с помощью !check в опциях PKGBUILD/makepkg или вызвать makepkg с флагом —nocheck .
Функция package()
Последний шаг — поместить скомпилированные файлы в каталог, из которого makepkg сможет получить их для создания пакета. По умолчанию это каталог pkg — простая среда fakeroot. Каталог pkg повторяет иерархию корневой файловой системы путей установки программного обеспечения. Если вам нужно вручную поместить файлы в корень вашей файловой системы, то вы должны установить их в каталог pkg в той же структуре каталогов. Например, если вы хотите установить файл в /usr/bin — вместо этого его следует поместить в $pkgdir/usr/bin . Очень немногие процедуры установки требуют от пользователя копирования десятков файлов вручную. Вместо этого для большинства программ достаточно вызвать команду make install . Чтобы правильно установить программу в каталог pkg последняя строка должна выглядеть следующим образом:
make DESTDIR="$pkgdir/" install
Note В некоторых случаях DESTDIR не используется в Makefile ; Вам может понадобиться использовать prefix вместо этого. Если пакет собран с помощью autoconf/ automake, используйте DESTDIR ; именно это документировано в руководствах. Если DESTDIR не работает — попробуйте собрать с помощью make prefix=»$pkgdir/usr/» install . Если и это не сработает, то Вам придется подробнее изучить команды установки, выполняемые командой » make <. >install «
В некоторых странных случаях программа ожидает запуска из одного каталога. В таких случаях разумно просто скопировать их в $pkgdir/opt .
Чаще всего процесс установки программного обеспечения создает все подкаталоги внутри каталога pkg . Однако если этого не происходит — makepkg будет выдавать множество ошибок и вам придется вручную создавать подкаталоги, добавляя соответствующие команды mkdir -p в функцию build() перед запуском процедуры установки.
В старых пакетах не было функции package() . Поэтому файлы помещались в каталог pkg в конце функции build() . Если package() отсутствует — build() запускается через fakeroot. В новых пакетах функция package() обязательна и запускается через fakeroot, а build() запускается без специальных привилегий.
makepkg —repackage запускает только функцию package() , поэтому создает файл *.pkg.* без компиляции пакета. Это может сэкономить время, например, если вы просто изменили переменную пакета depends .
Note Функция package() является единственной обязательной функцией в PKGBUILD. Если для установки программы Вам нужно только скопировать файлы в соответствующие каталоги — не помещайте их в функцию build() — поместите их в функцию package()
Тестирование PKGBUILD и пакета
В процессе написания функции build() Вам придется часто тестировать свои изменения чтобы убедиться в отсутствии ошибок. Это можно сделать с помощью команды makepkg в каталоге, содержащем файл PKGBUILD . При правильно оформленном PKGBUILD makepkg создаст пакет; при поврежденном или незавершенном PKGBUILD он выдаст ошибку.
Если makepkg завершится успешно — он поместит файл с именем pkgname-pkgver.pkg.tar.xz в ваш рабочий каталог. Этот пакет можно установить с помощью команды pacman -U . Однако то, что файл пакета был собран, не означает что он полностью работоспособен. Он может содержать только каталог и ни одного файла, если, например, префикс был указан неправильно. Вы можете использовать функции запроса pacman для отображения списка файлов, содержащихся в пакете, и зависимостей, которые он требует, с помощью pacman -Qlp [файл пакета] и pacman -Qip [файл пакета] соответственно.
Если пакет выглядит нормально, то все готово! Однако, если Вы планируете выпустить файл PKGBUILD — обязательно проверьте и перепроверьте содержимое массива depends .
Также убедитесь что двоичные файлы пакета действительно «запускаются» безупречно! Очень неприятно выпускать пакет, содержащий все необходимые файлы, но работающий со сбоями из-за какого-то непонятного параметра конфигурации, который не совсем хорошо работает с остальной системой. Однако, если вы собираетесь компилировать пакеты только для своей системы, то не стоит слишком беспокоиться об этом этапе проверки качества, поскольку, в конце концов, вы единственный человек, страдающий от ошибок.
Проверка исправности пакета
После тестирования функциональности пакета проверьте его на наличие ошибок с помощью namcap:
$ namcap PKGBUILD $ namcap .pkg.tar.xz
- Проверять содержимое PKGBUILD на наличие распространенных ошибок и иерархию файлов пакета на наличие ненужных/замещенных файлов.
- Сканировать все ELF-файлы в пакете с помощью lddd , автоматически сообщая, какие пакеты с необходимыми разделяемыми библиотеками отсутствуют в depends , а какие могут быть опущены как переходные зависимости.
- Эвристически искать отсутствующие и избыточные зависимости
и многое другое. Возьмите за привычку проверять свои пакеты с помощью namcap чтобы избежать необходимости исправлять простейшие ошибки после отправки пакета.
Отправка пакетов в AUR
Пожалуйста, прочитайте Arch User Repository — Отправка пакетов для подробного описания процесса отправки.
Резюме
- Скачайте исходный tarball программы, которую вы хотите упаковать.
- Попробуйте скомпилировать пакет и установить его в произвольный каталог.
- Скопируйте прототип /usr/share/pacman/PKGBUILD.proto и переименуйте его в PKGBUILD во временный рабочий каталог — предпочтительно ~/abs/ .
- Отредактируйте PKGBUILD в соответствии с потребностями вашего пакета.
- Запустите makepkg и проверьте правильно ли собран полученный пакет.
- Если нет — повторите два последних шага.
Предупреждения
- Прежде чем автоматизировать процесс сборки пакета Вы должны были хотя бы раз проделать это вручную, если только не знаете точно, что Вы делаете заранее, и в этом случае не читали бы это в первую очередь. К сожалению, хотя многие авторы программ придерживаются трехэтапного цикла сборки » ./configure ; make ; make install » — он не всегда таков и ситуация может стать действительно ужасной, если придется применять патчи, чтобы заставить все работать. Эмпирическое правило: если Вы не можете заставить программу скомпилироваться из исходного tarball’а и установить ее в определенный временный подкаталог — не стоит даже пытаться упаковать ее. В makepkg нет волшебного порошка, который заставит проблемы с исходниками исчезнуть.
- В некоторых случаях пакеты даже не доступны в виде исходников и придется использовать что-то вроде sh installer.run чтобы заставить их работать. Вам придётся провести довольно много исследований (прочитать README, инструкции INSTALL, man-страницы, возможно, ebuilds от Gentoo или других установщиков пакетов, возможно, даже MAKEFILE или исходный код), чтобы заставить его работать. В некоторых действительно плохих случаях Вам придется редактировать исходные файлы чтобы заставить его работать вообще. Однако, makepkg должен быть полностью автономным — не вмешивать пользователя. Поэтому, если Вам нужно отредактировать make-файлы, то возможно, придется подключить пользовательский патч к PKGBUILD и установить его изнутри функции prepare() , или же придется выполнить некоторые команды sed изнутри функции prepare() .
Создание файл патча
Пример для отдельного файла
$ diff -Naur filename.ext.old filename.ext > filename-patchname.diff # PKGBUILD cd "$/$-$" patch -uN filename.ext ../filename-patchname.diff || return 1
Пример для нескольких файлов
$ diff -Naur package-ver.old package-ver > package-patchname.diff # PKGBUILD cd "$/$-$" patch -uNp1 -i ../$-patchname.diff || return 1
- Contents Page/ru
- Development/ru
Cookie-файлы помогают нам предоставлять наши услуги. Используя наши сервисы, вы соглашаетесь с использованием cookie-файлов.
Руководство для начинающих по Pamac в Manjaro Linux
Pamac — графический менеджер пакетов по умолчанию в Manjaro Linux. Изучение того, как управлять пакетами с помощью Pamac, важно для каждого пользователя Manjaro.
Manjaro Linux стал известен как более простая в установке и использовании версия Arch Linux. Частично эта репутация связана с вашей способностью использовать Manjaro при полном отсутствии знаний о командной строке. Существуют графические приложения для установки самого Manjaro и установки программного обеспечения. Вот тут-то и появляется Памак.
Pamac — графическое приложение по умолчанию для установки программного обеспечения в различных версиях Manjaro. Хотя это несложно в использовании, не каждый компонент интуитивно понятен новичку, так что давайте углубимся.
Начало работы с Памак
Pamac содержит три вкладки вверху: «Обзор», «Установлено» и «Обновления». Это покажется вам знакомым, если у вас есть опыт работы с программным обеспечением GNOME или его различными версиями, такими как Ubuntu Software.
Хотя Pamac напоминает программное обеспечение GNOME, последнее больше похоже на магазин приложений, тогда как Pamac больше похож на менеджер пакетов. Это может показаться тонкой разницей, но это означает, что для одного требуется больше технических знаний, чем для другого. Приложения поставляются в комплекте и распространяются в виде пакетов, но не все пакеты являются приложениями. Компоненты фоновой системы и инструменты командной строки также поставляются в виде пакетов. Вы можете управлять этими пакетами в Pamac так, как вы не можете в инструменте, который больше похож на магазин приложений.
Тем не менее, ваш опыт работы с программным обеспечением GNOME сохраняется здесь. И если Pamac — ваш первый менеджер пакетов Linux, эти три вкладки, к счастью, говорят сами за себя. Обзор – это место, где вы можете найти новое программное обеспечение, Установлено – это то, что уже установлено на вашем компьютере, а Обновления – проверка наличия более новых версий установленного программного обеспечения.
Синхронизация базы данных с Pamac
Pamac может справиться с большинством аспектов управления программным обеспечением. Сюда входит добавление репозиториев программного обеспечения и обновление баз данных программного обеспечения.
Репозитории программного обеспечения — это удаленные серверы, на которых хранится программное обеспечение, доступное для вашего конкретного дистрибутива. По умолчанию Pamac показывает четыре репозитория Manjaro: основной, дополнительный, сообщество и мультибиблиотека.
Ваш локальный компьютер хранит записи о том, какое программное обеспечение доступно, и о текущих версиях указанного программного обеспечения. Эта информация поступает в локальную базу данных. Когда вы проверяете наличие более новых версий программного обеспечения, вам необходимо обновить базу данных. Вы можете сделать это вручную, нажав кнопку меню-гамбургера в строке заголовка и выбрав Обновить базы данных.
Установка и удаление программного обеспечения в Pamac
Теперь, когда вы добавили желаемые источники программного обеспечения и обновили свои базы данных, пришло время установить и удалить программное обеспечение. Процесс для этого одинаков независимо от того, находитесь ли вы на вкладке Обзор или на вкладке Установлено.
Когда вы прокрутите до приложения, которое хотите установить, вы увидите зеленый значок со стрелкой вниз. Щелкните здесь, чтобы начать загрузку. Если приложение уже установлено, вместо зеленого квадрата вы увидите красный квадрат с мусорной корзиной. Щелкните здесь, чтобы удалить программное обеспечение.
Если щелкнуть приложение, для удаленного ПО появится зеленая кнопка Установить. Установленное программное обеспечение будет иметь зеленую кнопку Запустить рядом с красной кнопкой Удалить.
На странице приложения есть раздел с подробным описанием зависимостей. Это программы, которые вам необходимо установить для запуска рассматриваемого приложения. Если эти программы еще не установлены на вашем компьютере, Pamac автоматически загрузит и установит их в процессе установки вашего приложения.
Для получения дополнительной информации вы можете перейти в раздел Файлы. Там вы можете увидеть список всех файлов, которые появятся на вашем компьютере в результате установки приложения. Это включает в себя двоичные файлы, а также базу данных или файлы изображений, необходимые для запуска.
Включить AUR в Pamac
Manjaro основан на Arch Linux, и вы можете установить на Manjaro любое программное обеспечение, доступное для Arch Linux. Это включает в себя программное обеспечение в пользовательском репозитории Arch или сокращенно AUR.
AUR — это место для программного обеспечения, которое еще не доступно в официальных репозиториях Arch Linux или не совсем того типа программ, которые Arch Linux собирает в комплекте. Если программа недоступна в официальных репозиториях, есть большая вероятность, что она доступна в AUR.
Если вы хотите выполнять поиск в AUR всякий раз, когда вы ищете программное обеспечение в Pamac, увеличивая ваши шансы найти то, что вы ищете, то вам сначала нужно включить AUR. К счастью, вам не нужно далеко ходить, чтобы понять, как это сделать. Просто нажмите кнопку меню и выберите Настройки. Затем перейдите на вкладку Сторонние. Там вы увидите переключатель рядом с Включить поддержку AUR.
Включить Flatpak и Snap в Pamac
Несмотря на то, что в репозиториях Arch и AUR доступно огромное количество программного обеспечения, использование приложений, доступных в одном из универсальных форматов пакетов, имеет свои преимущества. Они поставляются с дополнительными преимуществами безопасности. Хотя песочница не является железной, эти приложения часто ограничивают доступ к тем аспектам вашего компьютера, к которым программа может получить доступ.
Если вы используете несколько компьютеров с разными дистрибутивами Linux, универсальный формат пакета позволяет запускать одну и ту же версию программы на каждом компьютере. Это обеспечивает большую согласованность.
Два формата пакетов стали наиболее популярными: формат Flatpak, используемый многими дистрибутивами Linux, и формат Snap, который в основном используется в Ubuntu. Оба могут работать на большинстве дистрибутивов, а Manjaro из коробки поддерживает прямо в Pamac.
Просто вернитесь в то же меню, где вы нашли возможность включить поддержку AUR, и прокрутите вниз. Ниже вы увидите параметры Включить поддержку Flatpak и Включить поддержку Snap.
Pamac — жизненно важная часть вашей машины Manjaro
Многие люди используют Manjaro, потому что он предлагает гибкость Arch Linux, не требуя столько времени или технических знаний для использования. Pamac является примером того, как это происходит. Традиционный Arch Linux использует инструмент командной строки pacman, тогда как Pamac объединяет большую часть тех же функций в простое в использовании графическое приложение.
Тем не менее ничто не мешает вам использовать pacman на Manjaro, и это может быть быстрее, чем использование Pamac. Если вы хотите изучить pacman, продолжайте читать, чтобы изучить некоторые из наиболее полезных команд.
Все права защищены. © Linux-Console.net • 2019-2023
Пакеты приложений в Manjaro Linux
Вообщем планирую перейти на Manjaro Linux, сейчас на Linux Mint. Вчера затестил в Live-режиме, всё понравилось. Так вот, вопрос следующий: Есть в Manjaro Linux аналоги пакетов приложений типа *.appimage или *.deb? Сейчас на Linux Mint у меня с 10-ок приложений в формате *.appimage и *.deb, храню как архив, чтобы потом, если я переустановлю систему я мог просто устанавливать их без подключения к интернету. Есть ли аналоги таких пакетов в Manjaro?
Отслеживать
задан 21 июн 2021 в 5:30
Владимир Вилисов Владимир Вилисов
17 4 4 бронзовых знака1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Можно скачать пакет ввиде архива tar.xz , который потом можно будет установить.
Скачать (файл будет сохранен в /var/cache/pacman/pkg/ ):
pacman -Sw
pacman -U
Отслеживать
ответ дан 21 июн 2021 в 8:55
Exploding Kitten Exploding Kitten
5,447 2 2 золотых знака 18 18 серебряных знаков 24 24 бронзовых знака- linux
- linux-mint
- manjaro
-
Важное на Мете
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.