Файл pkgbuild не существует

Обновлено: 02.07.2024

Статья посвященная работе с пользовательским репозиторием Archlinux. Постарался сделать акцент на сопровождении пакетов. Данная статья, в большей степени, представляет собой компиляцию нескольких англоязычных статей Wiki и немного личного опыта. Поэтому не уверен, что в данной статье на английском языке будет толк.

Итак, Arch User Repository (AUR или АУР) - это репозиторий, поддерживаемый и развиваемый практически исключительно сообществом Archlinux. Есть еще отдельные люди, называемые доверенными пользователями (TU), на плечах которых лежит своеобразная “модерация” этого репозитория. На мой скромный взгляд, едва ли не единственное отличие Archlinux от других дистрибутивов - это наличие AUR’а. Отличие этого репозитория от обычных прежде всего в том, что он не содержит архивов с исходниками или собранных пакетов

только скрипт сборки (PKGBUILD) и, возможно, дополнительные текстовые файлы.

Конечно, вручную скачивать архив с сайта AUR’а, а также проверять обновления, не совсем удобно, поэтому существует набор хелперов. Большинство хелперов представляет собой обертку над pacman. Я выделю только два - packer - минималистичный, удобный, быстрый - и yaourt - на шелле, но зато более функциональный. По не особо понятным мне причинам, в русскоязычном сегменте большее распространение получил yaourt, зарубежом - packer.

Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю, пожалуй, только один - python-aur. Иногда удобная альтернатива веб-интерфейсу.

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

У пакетов в AUR есть несколько характеристик, которых нет у пакетов в официальных репозиториях:

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

Установка с AUR

Для работы с AUR требуется установить группу пакетов base-devel. Пакеты с этой группы, как правило, не включены в зависимости. Рекомендуемая установка пакетов с AUR выглядит примерно так:

Загрузка пакета в AUR

Никаких makepkg -S . С недавних пор данный метод считается устаревшим. Но обо всем по-порядку

Нам нужно загрузить архив на сайт. В этом архиве должны быть PKGBUILD и .AURINFO. По поводу первого я расскажу еще чуть ниже, второй генерируется автоматически. Также, там могут быть установочные скрипты (*.install), патчи, файлы лицензии (если не предоставляются апстримом с исходниками), сервисы systemd, скрипты запуска - это то, что обычно включено. Никаких исходников. И тем более никаких бинарников. (Шутки-шутками, а я помню пакет, в котором исходный код записывался с помощью cat << EOF прямо в тексте PKGBUILD’а.)

Все файлы кладем в одну директорию. Убедились, что install файл, если он есть, указан в переменной install, все другие исходные файлы указаны в массиве source, а хэш-суммы правильные (их легко можно сгенерировать, набрав makepkg -g ). Далее из этой директории запустить команду mkaurball (пакет pkgbuild-introspection) - и архив готов.

Несколько правил загрузки пакета в AUR:

Если такой пакет существует в официальном репозитории (любой версии), то не нужно заливать новый пакет. Если репозиторный пакет устарел, просто пометьте его, как устаревший. Исключение из этого правила составляют пакеты из системы контрля версий (VCS), о них чуть ниже.
Проверьте AUR. Если такой пакет уже существует и у него есть мейнтейнер, вы не сможете залить свой пакет. Если у него нет мейнтейнера, то вы автоматически будете его сопровождающим после обновления. Еще может быть такой же пакет, но с другим названием, будьте внимательны.
PKGBUILD должен следовать (более-менее) стандартам и должен быть более-менее аккуратным. В противном случае, пакет может быть удален без предупреждения.
Пакет должен быть полезен еще кому-либо кроме Вас =)
Рекомендуется проверить собранный пакет и PKGBUILD с помощью namcap. Это не даст 100% гарантии, но на основные ошибки укажет.

Сопровождение пакетов

Если вы сопровождаете пакет и хотите его обновить, просто загрузите обновленный пакет еще раз. Читайте - и, по возможности, отвечайте - комментарии к вашему пакету, там иногда могут быть очень полезные замечания или дельные предложения. Если вы не хотите сопровождать больше ваш пакет (или нет времени), то, пожалуйста, нажмите на кнопку справа (бросить/disown), чтобы те, кто в нем заинтересован, смогли поддерживать его. Если есть пакет, который не имеет сопровождающего, и вы хотели бы им стать, вы также можете нажать на соответствующую кнопку справа в веб-интерфейсе =)

Список рассылки AUR

По любому вопросу, связанному с работой AUR вы всегда можете обратиться в список рассылки aur-general (at) archlinux (dot) org. На ваш вопрос ответят, вероятно, достаточно быстро; причем, ответить могут не только обычные пользователи, но и доверенные пользователи. Также, если вы вдруг неуверены в своем PKGBUILD’е, вы тоже можете всегда обратиться в список рассылки и показать свой PKGBUILD.

Существует также отдельный список рассылки для запросов aur-requests (at) archlinux (dot) org. На текущий момент (AUR 3.2.0) общение через данный список рассылки напрямую не рекомендуется - все обычные запросы должны отсылаться с использованием веб-интерфейса (подробности). Запросы, которые вы можете послать:

Удаление пакета. Запрос должен включать краткое описание причины, почему вы его хотите удалить. Обычные причины - специальный патч, который больше не нужен; пакет уныл и более не поддерживается апстримом; переименование; функциональность предоставляется другим пакетом.
“Бросить пакет”. Лишить текущего мейнтейнера права сопровождать данный пакет. Официальное требование - вы должны связаться до этого с мейнтейнером по e-mail и ожидать от него ответа в течение двух недель (теперь это делается автоматически при отправке запроса через веб-интерфейс). Однако, если мейнтейнер неактивен в течение длительного времени, или пакет помечен, как устаревший, в течение длительного времени, то можно сделать исключение из этого правила. (Например, если пакет отмечен устаревшим более шести месяцев, то запрос удовлетворяется автоматически.)
Объединение пакетов. Если пакет подлежит удалению, но имеет голоса (или важные комментарии), то его можно объединить с другим, который предоставляет то же самое. Частный случай - это аналогично переименованию пакета из одного в другой.

Пожалуйста, пишите письма в список рассылки аккуратно. И, желательно, вежливо (а то потом будете генерировать что-то вроде такого) (мы все знаем, что мы арче-школьники, не надо нас еще раз этим тыкать, мы обидимся). Также старайтесь избегать избыточного цитирования. И - это практически требование - предоставляйте ссылки на пакеты. Хороший вариант - составление списка ссылок в конце письма, а в теле ссылаться на них таким образом [1] . Если не уверены в корректности запроса - посмотрите архив списка рассылки.

PKGBUILD

PKGBUILD - это, де-факто, сценарий шелла, указывающий как и почему (в смысле, зачем) собираться пакету. Он имеет 4 части:

Объявление основных переменных. Об этом я расскажу чуть ниже.
Подготовка исходников. Этот пункт необязательный. Включает в себя копирование (если вдруг нужно), применение патчей, sed и прочие мелочи. Функция обозначается, как prepare().
Сборка. Также необязательный пункт. Здесь - и только здесь - должна проводиться компиляция. Функция обозначается, как build().
Установка. Обязательный пункт. Здесь происходит копирование нужных файлов в указанный корень ( $pkgdir ). Функция обозначается, как package() (для совмещенных пакетов таких функций несколько и они называются примерно так: package_$pkgname()).

Переменные PKGBUILD

Основные переменные следующие:

pkgbase - группа пакетов. Например, пакеты python-pyqt4 и python2-pyqt4 имеют одну группу pyqt4 .
pkgname - имя (или массив имен для совмещенных пакетов) пакета; обязательная переменная.
pkgver - версия пакета, указанная в апстриме, pkgrel - арче-специфичный релиз пакета.
pkgdesc - краткое описание пакета.
arch - массив архитектур. Как правило, arch=('i686' 'x86_64') для бинарных пакетов (очень-очень редко бывают пакеты, которые предоставляются только для одной архитектуры) и arch=('any') для пакетов, не содержащих бинарные файлы.
url - адрес апстрима.
license - лицензия. Если лицензия отлична от обычных (распространенные типы MIT, BSD и custom) - смотри пакет core/licenses - то ее надо установить вместе с пакетом по пути /usr/share/licenses/$pkgname/LICENSE ).
depends - массив зависимостей, необходимых для работы пакета. optdepends - это дополнительные зависимости, которые не необходимы для работы, но предоставляют дополнительную функциональность. makedepends - это зависимости, которые не включены в depends, но необходимы при сборке пакета. Лучший способ проверить, правильно ли указаны зависимости сборки (зачастую, это самое важное) - попробуйте собрать пакет в чистом окружении (то есть совсем совсем чистом). И да, зависимости из группы base-devel указывать не надо.
Следующие три переменные необязательны. provides - список пакетов, функциональность которых предоставляет данный пакет. replaces - список пакетов, которые данный пакет замещает (обычно используется для решения проблем с переименованием пакетов при обновлении). conflicts - список пакетов, с которым конфликтует данный пакет (имеет такие же файлы). Пример различия provides и replaces - gvim предоставляет vim, а wireshark-gtk замещает wireshark.
install - файл, содержащий сценарии, запускающиеся после установки/удаления/обновления (смотрите файл /usr/share/pacman/proto.install ).
source - где брать исходники, файлы предоставляемые вместе с пакетом указываются только по имени, к данному массиму также прилагается массив хэш сумм (md5sums/sha1sums/sha256sums/sha384sums/sha512sums).

Все перечисленные выше переменные указываются в заголовке PKGBUILD. К ним также можно обращаться внутри PKGBUILD’а. Дополнительно стоит упомянуть переменные startdir - директория, откуда запускается makepkg, srcdir - директория с исходниками ( $startdir/src по умолчанию), pkgdir - директория с собранным пакетом ( $startdir/pkg/$pkgname по умолчанию). Не используйте переменную startdir без крайней необходимости.

Некоторые особенности PKGBUILD’ов

К PKGBUILD применимы все правила программирования на шелле. Например, “смешная шутка”:

кому-то может показаться не очень смешной, увы. Поэтому все пути (да и вообще переменные - там где надо, конечно) лучше обрамлять в двойные кавычки (исключение - условия в двойных квадратных скобках [[ . ]] ). Если вы вводите какие-либо свои переменные, то настоятельно рекоммендуется добавить в начале подчеркивание _ во избежание перекрытия переменными makepkg.

В русскоязычном сегменте до сих пор зачастую встречаются строки типа make || return 1 . Дык вот, return 1 теперь уже давно как не нужен.

Еще можно работать с рядом других переменных, определенных makepkg. Их список можно глянуть в /etc/makepkg.conf . Самые ходовые - флаги компиляции и CARCH . Так, например, если вы собираете пакет, исходники к которому предоставляются в бинарном виде (проприетарный драйвер, например), то кусок PKGBUILD может выглядеть так:

Вообще говоря, для стандартных случаев существуют прототипы PKGBUILD’ов. Их можно найти в /usr/share/pacman/ , хотя местами они могли немного устареть (больше года как). Так, прототипы для пакетов из системы контроля версий (git/svn/hg/bzr) однозначно устарели - сейчас используется другой, куда более аккуратный, формат. Настоятельно рекомендую ознакомиться на эту тему с данной статьей. Например, для пакета qmmp-qsmmp-git кусок PKGBUILD’а выглядит так:

А для пакета kdeplasma-applets-stdin-svn так:

Также, я отмечу, что некоторые пакеты имеют свой устоявшийся формат, поэтому, зачастую, полезно поискать что-то похожее в AUR и сделать свой PKGBUILD по образу и подобию.

В связи со стремительным набором популярности я заметил, что на manjaro стремительно стали пробовать переходить убунтоводы, минтовцы и прочие дебианщики. Очень часто наблюдаю комментарии, что в манджаро apt-get не работает или рекомендации установить deb-пакет при помощи dpkg. Такие фразы периодически веселят, но когда это происходит практически каждый день в телеграмм-чате я все-таки решился написать маленький how-to как же все-таки написать PKGBUILD и установить приложение, которого нет в аур. Писатель из меня никудышный, поэтому не стоит оценивать перо автора очень критично. И так приступим.
Для начала немного теории. PKGBUILD — это обычный текстовый файл с набором инструкций по сборке пакетов для арчеподобных дистрибутивов. На выходе мы должны получить пакет с расширением *.pkg.tar.xz. По сути это просто архив с установочными файлами пакетов и информацией об устанавливаемом пакете. с помощью PKGBUILD можно написать инструкцию по сборке пакета из *.deb, *.rpm, их исходников и даже просто из обычного архива файлов. Главное понимать что ты собираешься получить на выходе.

Пример написания PKGBUILD для сборки из deb

для примера я возьму IPTV-player украинского разработчика Вячеслава Зубика ZVVOnlineTV, которого, кстати нет в аур`е.
Скачиваем deb-пакет с сайта и помещаем его в отдельный каталог(для удобства).
рядом с файлом создаем текстовый файл и присваиваем ему имя PKGBUILD. готово!
открываем его в текстовом редакторе.
Итак. первая строка не обязательна и не несет какой-либо инструктивности, а просто говорит нам кто разработчик

имя пакета,
здесь все подробно описано.
далее создадим типа «переменную» с именем ZVVOnlineTV

здесь скажу пару слов. Так как ОС линукс чувствительна к регистру, то нам нужно это дело как-то обозначить.
следующее

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

так как имя скачанного файла ZVVOnlineTV2_1.deb, то нужно создать еще одну переменную.

присваиваем версию релиза.

и ссылку на источник.

указываем лицензию, я не знаю под какой лицензией разработчик распространяет это приложение. поэтому custom
далее определяем зависимости, которые необходимы для работы приложения, они есть на сайте разработчика

Для запуска ТВ в системе должны быть установлены:
1. Библиотеки PyQt5 и Gstreamer

какие нужны зависимости, ищите в инструкциях разрабов или гуглением или посредством вылова ошибок при работе программы, — если вдруг начала ругаться, что не хватает какой-то библиотеки, значит это необходимая зависимость. )
Некоторые пакеты в арчеподобных системах называются немного иначе, но, думаю, кому надо, — разберется!
Идем далее

здесь мы показываем источник, из которого мы будем брать данные(файлы программы) для сборки, вот как раз сдесь нам и пригодятся наши переменные $ — это имя пакета ZVVOnlineTV, а $ — это его версия 2_1 использованная в имени файла, далее ставим точку и указываем расширение deb.
в source можно указать и url-ссылку на исходный файл, если их несколько то они перечисляются в кавычках через пробел:

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

Далее переходим непосредственно к сборке.

Когда начнется сборка, то в каталоге, где вы разместили файл ZVVOnlineTV2_1.deb и создали PKGBUILD будет создано две директории src и pkg. Так вот файл ZVVOnlineTV2_1.deb (это по сути архив) распакуется в директорию src и в ней будут лежать наши файлы data.tar.xz, control.tar.gz, debian-binary и прочее.
Командой cd "$" мы говорим скрипту что нужно переместиться именно в эту директорию для продолжения работы, вторая команда распаковывает архив data.tar.xz в директорию pkg. Дальше все это дело благополучно упакуется а архив с именем zvvonlinetv-2.1-1-x86_64.pkg.tar.xz.
прочитав до этого момента вы должны спросить, а когда же все-таки начнется сборка, и я отвечу, что для сборки пакета нужно открыть терминал в каталоге с этими файлами и запустить команду

после того как скрипт отработает его можно установить командой

где package_name имя вашего пакета, в данном случае zvvonlinetv-2.1-1-x86_64.pkg.tar.xz

Пример написания PKGBUILD для сборки из исходников

для примера я возьму выключалку компьютера qshutdown, которой тоже нет в ауре
Подробно описывать не буду, а опишу только некоторые отличия.
В файле README описана инструкция по установке и необходимые зависимости для работы программы.
итак отличие будет в том, что у нас будет 2 секции build()<> и package() <>

Порядок выполнения команд такой же как описано в README файле, единственное на что нужно обратить внимание, так это на строку

в связи с тем что команду make install нужно выполнять от суперпользователя, в скрипте нужно это указать, чтобы во время сборки была создана имитация рут-установки.
пример PKGBUILD`a

Напоследок несколько ключей для работы с makepkg
makepkg -i — собирает и устанавливает пакет,
makepkg -s — устанавливает завизимости и собирает пакет
makepkg -si — угадайте)))
makepkg -g — выдает контролюную сумму пакетов.

Про сборку из rpm-пакетов не буду вдаваться в подробности, единственное, что должен быть установлкен rpmextract/pkgextract.

Мы создаем установщик для Audio Plugin, используя pkgbuild. Он состоит из нескольких пакетов (VST, AU, Content, Presets и т.д.). Поскольку контент довольно велик, мы хотим разрешить пользователям у.

Наш установщик pkgbuild правильно показывает "Не удалось выполнить установку". окна при возникновении ошибки. Но над этим заголовком появляется небольшая текстовая строка Apple "Были ошибки при уст.

Как включить файлы, необходимые для сценариев preinstall/postinstall при создании.pkg в mac osx? Я выполнил эту команду в терминале и создал.pkg; однако ничего не происходит, когда я дважды кликнул.

Как создать pkg installer на yosemite. Мне нужно установить программу для java-приложения, которая должна делать некоторые обновления файлов во время установки. Есть один для Xcode 4, но я не увере.

Я собираю пакет установщика для OS X, и я не могу понять, как отключить экран, который запрашивает у пользователя, на какой том установить. Я хочу, чтобы он устанавливался в / без подсказки. Вот ка.

Создание пакета для Mac OS, У меня есть application.app, который успешно завершил код, используя утилиту "codesign". Когда я создаю пакет, используя pkgbuild. он правильно создает application.pkg, .

Я перестраиваю существующий pkg с помощью продукта. Мой корневой путь выглядит так: ROOT> Приложения/Скрипты/Library/частные/ В приложениях/это мой.app, который работает. Однако в Библиотеке, на.

Я строю свой установщик на сервере сборки. Я использую эту команду для сборки pkg. pkgbuild --root MyApp.app --identifier com.MyApp --install-location /Applications/MyApp.app MyApp.pkg Это работает.

У меня есть небольшой скрипт, который использует некоторые статические текстовые файлы в качестве источника данных. Я хочу сделать пакет Archlinux AUR для этого скрипта. Я планирую установить скрип.

Я пытаюсь установить компилятор XDS-x86. Я загрузил пакет, но когда я набираю makepkg, я получаю ошибку: ERROR: PKGBUILD не существует. Любые подсказки?

Я пытаюсь собрать qz.io из исходного кода, чтобы он использовал самозаверяющий сертификат. По этой ссылке они показывают способ сборки из исходного кода и подписывают его новым сертификатом: ant ns.

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

У нас есть настольное программное обеспечение для OSX, распространяемое за пределами Mac App Store, в виде пакета установки pkg. Нам хотелось бы установить расширение Safari вместе с настольным при.

У меня есть следующая структура каталогов в моем текущем рабочем каталоге (CWD): MyAppBundle/MyApp.app MyAppBundle.plist MyAppBundle.plist содержит следующее: <?xml version="1.0" encoding tag-list"> pkgbuild macos

Я использую pkgbuild productbuild для сборки установщика. Однако после установки на OS X 10.12 Sierra после завершения установки я вижу лист "Вы хотите переместить установщика в корзину?" Чтобы сох.

Я новичок в разработке приложений MAC и работаю над проектом, который использует Zoom Mac SDK, но SDK не поддерживает архив с Xcode, поэтому мне нужно сделать архив с другими инструментами, предлож.

Я последовал за несколькими учебными пособиями, которые, как казалось, говорили то же самое, - о том, как создавать развертываемые плоские пакеты (.pkg) с помощью системы OS X, предоставляемой инст.

Я использовал pkgbuild для создания файла списка свойств компонента по умолчанию. Файл выглядит так: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0/.

Я не могу представить способ конвертировать файлы из моего AWS S3 в файл.pkg на веб-сайте javascript. Файлы будут преобразованы и загружены обратно в AWS в виде pkg. Кто-нибудь знает, как сделать э.

контекст У меня большой пакет приложений. Я хочу разбить его на Набор приложений отдельно пакеты (с их собственными сценариями установки /pre/post flight и т.д.), содержащие исполняемые файлы, явля.

Я хочу создать установочный пакет для Mac OS X, который содержит 4 подпакета. Подпакеты создаются с помощью pkgbuild. Окончательный пакет создается с помощью productbuild с помощью Distrib.xml для .

Я pkgbuild установщик с помощью pkgbuild и productbuild . Я хотел бы иметь возможность собирать журналы установки у моих пользователей в случае, если что-то пойдет не так. Было бы неплохо, если бы .

Я хочу отключить кнопку "Изменить место установки. " (снимок экрана ниже) в установщике. Я пытаюсь создать установщик с помощью pkgbuild и productbuild на macOSX 10.8. Во-первых, я создаю два .pkg.

Могу ли я спросить, какой практический вариант для создания файла.pkg на ubuntu? Я пытался xar, но полученный файл.pkg не мог быть установлен на mac, получил 'com.apple.installer.pagecontroller err.

Мне нужно установить 2 аудио-плагина в корневые директории Audio/Plug-Ins/VST & Components. Мой установщик отлично справляется. Но мне также нужно установить каталог предустановленных файлов в .

У меня есть цель сборки, настроенная в моем проекте Xcode, чтобы создать пакет из нескольких других целей. Я добавил сценарий фазы сборки, который просто запускает productbuild , который может авто.

Я пытаюсь создать установщик для Java-приложения в Mac OS 10.8.4. Приложение работает нормально, и я могу установить его без заминки из zip файла. Я могу создать установщик .pkg с помощью либо prod.

Я создаю.pkg из других.pkg файлов. Когда я пытаюсь установить результирующий.pkg, я могу видеть только "установить" в диалоговом окне имя пакета не отображается в диалоговом окне установки. Как я м.

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

Я переношу наш установщик из PackageMaker в pkgbuild и пытаюсь установить местоположение установки по умолчанию в текущий домашний каталог пользователя и по-прежнему разрешать пользователю устанавл.

Имя файла PKG уникально для загрузки каждого пользователя. Имеет ли JS в файле Distribution.xml доступ к имени файла pkg или полному пути к файлу? Я знаю, что сценарии pre и post install имеют дост.

Я хочу бросить диалоговое окно ошибок (и не выполнить установку), если в системе существует определенный файл. Является ли это возможным? pkg = плоский файл pkg

У меня есть приложение mac (например, Sample.pkg, содержащее Sample.app), а также несколько зависимостей pkg (например, A.pkg и B.pkg). Всякий раз, когда пользователь запускает архив dmg/product в .

Я создаю установщик, используя pkgbuild и productbuild, и хочу, чтобы часть процесса включала задание пользователю простых вопросов. На эти вопросы могут ответить любые флажки (да/нет) или небольшо.

Я пытаюсь создать пакет, используя pkgbuild и архив продуктов, используя productbuild. Без скриптов установщик успешно устанавливает пакет. Но со сценариями он терпит неудачу. Я googled для этого, .

У меня есть странная проблема, когда мой установщик правильно перезаписывает ранее установленное приложение, но затем перезаписывает приложение в моем каталоге сборки. Моя сборка установщика выгляд.

Я использую пакеты для создания установщика PKG. Его цель довольно проста: доставьте мое приложение в папку /Applications и запустите его. Packages.app делает свою работу почти хорошо, кроме одного.

Рубрики

А так же делитесь знаниями, знакомьтесь с новыми утилитами и приложениями, учитесь у всегда готовых помочь ответить на самые сложные вопросы во всех сферах IT и программирования. Станьте гуру и экспертом разработки ПО, получите признание коллег, заработайте репутацию, создайте стартап или приложение которое будет работать на вас!

Debian/Ubuntu

Arch/Manjaro

Сборка программ c Github

Затем переходим в папку:

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

Обратите внимания, что GPArted хорошо документированная, и для установки под каждый дистрибутив имеется инструкция с дополнительными зависимостями. Устанавливаем зависимости и выполняем команду для того, что бы у вас сформировался установочный файл:

Если проблема с зависимостями у вас останется, то вы увидите об этом вывод:

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

После установки можно найти программу в меню установленных программ.

Сборка программ из архива

Распаковывать архив можно из терминала, а можно при помощи графического интерфейса, например программой Ark или Менеджер архивов. Тут все зависит от того, как вам удобней. Для того что бы распаковать архив в терминале, нужно выполнить определенную команду. На примере с GParted такой командой будет:

Примечание, tar является утилитой командной строки для распаковки архивов. И так, затем переходим в папку с распакованной программой и смотрим какие там имеются файлы. Тут как раз имеются README:

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

Теперь приступаем к сборке программы GParted. Для этого вводим команды которые написаны в файле README.

На этом этапе установки могут возникнуть проблемы с зависимостями. По этому их необходимо установить:

Ошибки при сборке программы

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

После того как вы установите необходимые зависимости, снова необходимо запустить ./configure. А может быть и так, что у вас не будет файла ./configure, попробуйте запустить другие скрипты:

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

Пример необходимых зависимостей при установки в Manjaro программы Blender. Компиляция производилась с использованием файла PKGBUILD:

Удаление программ

Если же вы захотите в будущем удалить GParted, или какую то иную программу, оставьте папку которую скачивали. Так как только в ней есть инструкция куда устанавливались те или иные пакеты. Обычно, в файле README написано как удалять установленные программы. В случае с GParted достаточно перейти в каталог с исходниками и выполнить команду:

Опишу опции которые тут применяются, опция -s произвести проверку и установку зависимостей, а опция i установку самого пакета:

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

Заключение

А на этом сегодня все. Надеюсь данная статья будет вам полезна.
С уважением Cyber-X

Читайте также: