Manjaro Difference between revisions of "Manjaro Packaging Standards/ru"

Difference between revisions of "Manjaro Packaging Standards/ru"

From Manjaro
(Created page with "* Пакеты не должны содержать ни одного из следующих каталогов: ** {{ic|/dev}} ** {{ic|/home}} ** {{ic|/srv}} ** {{ic|/media}...")
 
(34 intermediate revisions by 2 users not shown)
Line 3: Line 3:
'''Представленные PKGBUILD ни при каких обстоятельствах не должны собирать приложения, уже находящиеся в официальных бинарных репозиториях. Исключением из этого строгого правила могут быть только пакеты с включенными дополнительными функциями и/или патчами по сравнению с официальными. В этом случае массив pkgname должен быть другим.'''
'''Представленные PKGBUILD ни при каких обстоятельствах не должны собирать приложения, уже находящиеся в официальных бинарных репозиториях. Исключением из этого строгого правила могут быть только пакеты с включенными дополнительными функциями и/или патчами по сравнению с официальными. В этом случае массив pkgname должен быть другим.'''


When building packages for Manjaro Linux, '''adhere to the package guidelines''' below, especially if the intention is
При создании пакетов для Manjaro Linux, '''придерживайтесь руководства по созданию пакетов''', приведенного ниже, особенно если вы собираетесь
to '''contribute''' a new package
''внести свой вклад'' в новый пакет
to Manjaro Linux. You should also see the [https://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] and
для Manjaro Linux. Вам также следует ознакомиться с [https://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] и
[https://archlinux.org/pacman/makepkg.8.html makepkg] manpages.
[https://archlinux.org/pacman/makepkg.8.html makepkg] manpages.
==PKGBUILD prototype==
==Прототип PKGBUILD==
{{bc|1=
{{bc|1=
# Maintainer: Your Name <youremail@domain.com>
# Maintainer: Иван Иванов <ваша_почта@домен.ru>
pkgname=NAME
pkgname=NAME
pkgver=VERSION
pkgver=VERSION
Line 30: Line 30:
source=($pkgname-$pkgver.tar.gz)
source=($pkgname-$pkgver.tar.gz)
noextract=()
noextract=()
md5sums=() #autofill using updpkgsums
md5sums=() #автозаполнение с помощью updpkgsums


build() {
build() {
Line 46: Line 46:
}}
}}


Other prototypes are found in {{ic|/usr/share/pacman}} from the pacman and abs packages.
Другие прототипы можно найти в {{ic|/usr/share/pacman}} из пакетов pacman и abs.
==Этикет упаковки==
==Этикет упаковки==


<ul>
<ul>
<li>Packages should '''never''' be installed to {{ic|/usr/local}}</li>
<li>Пакеты никогда не должны устанавливаться в {{ic|/usr/local}}</li>
<li>
<li>
'''Do not introduce new variables''' into
{{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could
possibly '''conflict''' with variables used
in makepkg itself.


If a new variable is absolutely required,
'''Не вводите новые переменные''' в {{ic|PKGBUILD}}
'''prefix the variable name with an underscore''' ({{ic|_}}), e.g.
в скрипты сборки, если только пакет не может быть собран без этого, так как они могут '''конфликтовать''' с переменными, используемыми в самом makepkg.
 
Если новая переменная в самом деле необходима,
'''предварите её имя нижним подчеркиванием''' ({{ic|_}}), напр.
{{bc|1=_customvariable=}}
{{bc|1=_customvariable=}}


The AUR cannot detect the use of custom variables and so cannot use them in substitutions. This can most often be seen in the source array e.g.
AUR не может определить использование пользовательских переменных и поэтому не может использовать их в подстановках. Чаще всего это можно увидеть в исходном массиве, например.
{{bc|<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>}}
{{bc|<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>}}
Such a situation defeats the effective functionality of the AUR.
Такая ситуация противоречит эффективной функциональности AUR.
</li>
</li>


<li>
<li>
'''Avoid''' using {{ic|/usr/libexec/}} for
'''Избегайте''' использования {{ic|/usr/libexec/}} для для всего подряд. Вместо него используйте {{ic|/usr/lib/${pkgname}/}}.
anything. Use {{ic|/usr/lib/${pkgname}/}} instead.
</li>
</li>
<li>
<li>
The {{ic|packager}} field from the package meta file can be
Поле {{ic|packager}} из метафайла пакета может '''настраиваться''' создателем пакета путем изменения соответствующей опции в {{ic|/etc/makepkg.conf}}
'''customized''' by the package builder by modifying
the appropriate option in the {{ic|/etc/makepkg.conf}}


file, or alternatively override it by creating ~/.makepkg.conf
файл, или альтернативно переопределить его, создав ~/.makepkg.conf


</li>
</li>
<li>
<li>
All important messages should be echoed during install using an '''.install file'''. For
Все важные сообщения должны быть озвучены во время установки с помощью файла '''.install'''. Например, например, если пакет требует дополнительной настройки для работы, следует включить указания. </li>
example, if a package needs extra setup to work, directions should be included. </li>
             <li>Любые '''необязательные зависимости''', которые не нужны для запуска пакета или его общего функционирования, не должны быть включены; вместо этого информация должна быть добавлена в массив <b>optdepends</b>:
             <li>Any '''optional dependencies''' that are not
needed to run the package or have it generally function should not be
included; instead the information should be added to the <b>optdepends</b> array:
{{bc|1=
{{bc|1=
optdepends=('cups: printing support'
optdepends=('cups: printing support'
Line 94: Line 87:
}}
}}


The above example is taken from the <b>wine</b> package in {{Ic|extra}}. The optdepends
Приведенный выше пример взят для пакета <b>wine</b> в {{Ic|extra}}. Информация optdepends автоматически выводится при установке/обновлении, поэтому <b>не</b> следует хранить такую информацию в файлах .install.
information is automatically printed out on installation/upgrade so
one should <b>not</b> keep this kind of information in .install files.


</li>
</li>
         <li>When creating a '''package description''' for a package, do not include
         <li>При создании '''описания пакета''' для пакета не включайте имя пакета в виде самоссылки. Например, "Nedit is a text editor for X11" может быть упрощен до "A text editor for X11". Также старайтесь, чтобы описание не превышало ~80 символов.</li>
        the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11". Also try to keep the descriptions to ~80 characters or less.</li>
<li>Старайтесь, чтобы длина '''строки''' в PKGBUILD не превышала ~100 символов.</li>
<li>Try to keep the '''line length''' in the PKGBUILD below ~100 characters.</li>
<li>По возможности удаляйте пустые строки из {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}} и т.д.)</li>
<li>Where possible, '''remove empty lines''' from the {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)</li>
<li>Общепринятой практикой является '''сохранение порядка''' полей {{ic|PKGBUILD}}, как показано выше. Однако это необязательно, поскольку единственным требованием в данном контексте является '''правильный синтаксис bash'''.</li>
<li>It is common practice to '''preserve the order''' of the {{ic|PKGBUILD}} fields as shown above. However, this is not mandatory, as the only requirement in this context is '''correct bash syntax'''.</li>
</ul>
</ul>


==Package naming==
==Именование пакетов==
* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.
* Имена пакетов должны состоять только из '''буквенно-цифровых символов'''; все буквы должны быть '''строчными'''.
* Package names should NOT be suffixed with the upstream major release version number (e.g. we don't want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some can't (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.
* Имена пакетов НЕ должны иметь суффикс с номером версии основного выпуска upstream (например, нам не нужен libfoo2, если upstream называет его libfoo v2.3.4) в случае, если ожидается, что библиотека и ее зависимости будут использовать самую последнюю версию библиотеки с каждым соответствующим выпуском upstream. Однако не для всех программ или зависимостей можно ожидать подобное. В прошлом это было  верно для наборов инструментов виджетов, таких как GTK и Qt. Программное обеспечение, зависящее от таких наборов инструментов, как правило не может быть тривиально перенесено на новую основную версию. Поэтому в случаях, когда программы не могут тривиально продолжать развиваться вместе со своими зависимостями, имена пакетов должны содержать суффикс основной версии (например, gtk2, gtk3, qt4, qt5). Для случаев, когда большинство зависимостей могут продолжать распространяться вместе с новейшим релизом, но некоторые не могут (например, закрытый исходный код, требующий libpng12 или аналогичный), устаревшая версия пакета может называться libfoo1, а текущая версия - просто libfoo.
* Package versions '''should be the same as the version released by the author'''. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). '''Version tags may not include hyphens!''' Letters, numbers, and periods only.
* Версии пакетов '''должны быть такими же, как версия, выпущенная автором'''. Версии могут включать буквы, если это необходимо (например, версия nmap - 2.54BETA32). '''Теги версий не должны включать дефисы!'''. Только буквы, цифры и точки.
* Package releases are '''specific to Arch Linux packages'''. These allow users to differentiate between newer and older package builds. When a new package version is first released, the '''release count starts at 1'''. Then as fixes and optimizations are made, the package will be '''re-released''' to the Arch Linux public and the '''release number will increment'''. When a new version comes out, the release count resets to 1. Package release tags follow the '''same naming restrictions as version tags'''.
* Релизы пакетов - это '''специфические для Manjaro Linux пакеты'''. Они позволяют пользователям различать более новые и более старые сборки пакетов. Когда новая версия пакета выпускается впервые, счетчик релизов начинается с 1. Затем, по мере внесения исправлений и оптимизаций, пакет будет ''перевыпущен'' для публики Manjaro Linux и ''номер релиза будет увеличиваться''. Когда выходит новая версия, счетчик релизов обнуляется до 1. Теги релизов пакетов следуют тем же ограничениям именования, что и теги версий.
==Directories==
==Каталоги==
* '''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}} where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}).
* '''Конфигурационные файлы''' должны размещаться в каталоге {{ic|/etc}}. Если существует более одного файла конфигурации, обычно принято '''использовать подкаталог''', чтобы сохранить область {{ic|/etc}} как можно более чистой. Используйте {{ic|/etc/{pkgname}/}}, где {{ic|<nowiki>{pkgname}</nowiki>}} - имя пакета (или подходящую альтернативу, например, apache использует {{ic|/etc/httpd/}}).


* Package files should follow these '''general directory guidelines''':
* Файлы пакетов должны следовать этим '''общим рекомендациям по каталогам''':


:{|
:{|
|-
|-
| {{ic|/etc}}
| {{ic|/etc}}
| '''System-essential''' configuration files
| '''Системно-важные''' файлы конфигурации
|-
|-
| {{ic|/usr/bin}}
| {{ic|/usr/bin}}
| Binaries
| Двоичные файлы
|-
|-
| {{ic|/usr/lib}}
| {{ic|/usr/lib}}
| Libraries
| Библиотеки
|-
|-
| {{ic|/usr/include}}
| {{ic|/usr/include}}
| Header files
| Файлы заголовков
|-
|-
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}
| Modules, plugins, etc.
| Модули, плагины и тд.
|-
|-
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}
| Application documentation
| Документация приложений
|-
|-
| {{ic|/usr/share/info}}
| {{ic|/usr/share/info}}
| GNU Info system files
| Системные файлы GNU Info
|-
|-
| {{ic|/usr/share/man}}
| {{ic|/usr/share/man}}
| Manpages
| Страницы Man
|-
|-
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}
| Application data
| Данные приложений
|-
|-
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}
| Persistent application storage
| Постоянное хранение приложений
|-
|-
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}
| Configuration files for {{ic|<nowiki>{pkg}</nowiki>}}
| Файлы конфигураций для {{ic|<nowiki>{pkg}</nowiki>}}
|-
|-
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}
| Large self-contained packages such as Java, etc.
| Большие самодостаточные пакеты, такие как Java и т.д.
|}
|}


Line 168: Line 158:
** {{ic|/var/tmp}}
** {{ic|/var/tmp}}
** {{ic|/run}}
** {{ic|/run}}
==Makepkg duties==
==Обязанности Makepkg==


<p>
<p>
When [[makepkg]] is used to build a package, it does the
Когда [[makepkg/ru|makepkg]] используется для сборки пакета, он автоматически выполняет следующие действия:
following automatically:
</p>
</p>


<ol>
<ol>
<li>
<li>
Checks if package '''dependencies''' and '''makedepends''' are installed
Проверяет, установлены ли пакеты '''dependencies''' и '''makedepends'''.
</li>
</li>
<li>
<li>
'''Downloads source''' files from servers
'''Загружает исходные''' файлы с серверов
</li>
</li>
<li>
<li>
'''Checks the integrity''' of source files
'''Проверяет целостность''' исходных файлов
</li>
</li>
<li>
<li>
'''Unpacks''' source files
'''Распаковывает''' исходные файлы
</li>
</li>
<li>
<li>
Does any necessary '''patching'''
Применяет все необходимые '''патчи'''.
</li>
</li>
<li>
<li>


'''Builds''' the software and installs it in a fake
'''Собирает''' программное обеспечение и устанавливает его в поддельный корень
root
</li>
</li>
<li>
<li>
'''Strips''' symbols from binaries
'''Удаляет''' символы из двоичных файлов
</li>
</li>
<li>
<li>
'''Strips''' debugging symbols from libraries
'''Удаляет''' отладочные символы из библиотек
</li>
</li>
<li>
<li>
'''Compresses''' manual and, or info pages
'''Сжимает''' руководство и/или информационные страницы
</li>
</li>
<li>
<li>
Generates the '''package meta file''' which is included with each package
Генерирует '''мета-файл пакета''', который включается в каждый пакет
</li>
</li>


<li>
<li>
'''Compresses''' the fake root into the package file
'''Сжимает''' поддельный корень в файл пакета
</li>
</li>
<li>
<li>
'''Stores''' the package file in the configured destination directory (<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> by default)
'''Сохраняет''' файл пакета в настроенном каталоге назначения (<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> по умолчанию)
</li>
</li>


</ol>
</ol>
==Architectures==
==Архитектуры==
The {{Ic|arch}} array should contain {{Ic|'i686'}} and/or {{Ic|'x86_64'}} depending on which architectures it can be built on. You can also use {{Ic|'any'}} for architecture independent packages.
Массив {{Ic|arch}} должен содержать {{Ic|'i686'}} и/или {{Ic|'x86_64'}} в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать {{Ic|'any'}} для независимых от архитектуры пакетов.
==Licenses==
==Лицензии==
The [[Licenses|license]] array is being implemented in the official repos, and it <b>should</b> be used in your packages as well. Use it as follows:
Массив [[Licenses|license]] внедряется в официальные репозитории, и его <b>следует</b> использовать и в ваших пакетах. Используйте его следующим образом:
<ul>
<ul>
<li>A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL.  If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')</li>
<li>В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL.  Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=('GPL').</li>
<li>If the appropriate license is not included in the official licenses package, several things must be done:
<li>Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
<ol>
<ol>
<li>The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/LICENSE. One good way to do this is by using:
<li>Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать:
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
</li>
</li>
<li>If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then copy the license to a file and include it. Remember to call it something appropriate too.
<li>Если исходный tarball НЕ содержит сведений о лицензии, а лицензия отображается, например, только на сайте, то скопируйте лицензию в файл и включите его. Не забудьте также назвать его как-нибудь подходяще.
<li>Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.</li>
<li>Добавьте 'custom' в массив лицензий. По желанию вы можете заменить 'custom' на 'custom: "имя лицензии"'.</li>
</ol></li>
</ol></li>
<li>Once a licenses is used in two or more packages in an official repo, including [community], it becomes common</li>
<li>Как только лицензия используется в двух или более пакетах в официальном репозитории, включая [community], она становится общей</li>
<li>The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it is treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it is a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.</li>
<li>Лицензии MIT, BSD, zlib/libpng и Python являются особыми случаями и не могут быть включены в пакет 'common' пакета лицензий. Для переменной license они рассматриваются как обычные лицензии (license=('BSD'), license=('MIT'), license=('ZLIB') или license=('Python')), но для файловой системы это пользовательские лицензии, поскольку каждая из них имеет свою собственную строку копирайта. Каждый пакет с лицензией MIT, BSD, zlib/libpng или Python должен иметь свою уникальную лицензию, хранящуюся в /usr/share/licenses/$pkgname/.</li>
<li>Some packages may not be covered by a single license.  In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time.  When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.</li>
<li>На некоторые пакеты может распространяться не одна лицензия. В таких случаях в массиве лицензий может быть несколько записей, например license=("GPL" "custom:some commercial license"). Для большинства пакетов эти лицензии применяются в разных случаях, а не одновременно.  Когда pacman получит возможность фильтрации по лицензиям (так что вы сможете сказать: "Мне нужны только программы с лицензиями GPL и BSD"), две (или более) лицензии будут рассматриваться pacman с использованием логики ИЛИ, а не И, поэтому pacman будет рассматривать приведенный выше пример как программу с лицензией GPL, независимо от других перечисленных лицензий.</li>
<li>The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:</li>
<li>У (L)GPL есть много версий и перестановок этих версий. Для программ под (L)GPL существует следующая концепция:</li>
<ul>
<ul>
<li>(L)GPL - (L)GPLv2 or any later version</li>
<li>(L)GPL - (L)GPLv2 или любая поздняя версия</li>
<li>(L)GPL2 - (L)GPL2 only</li>
<li>(L)GPL2 - только (L)GPL2y</li>
<li>(L)GPL3 - (L)GPL3 or any later version</li>
<li>(L)GPL3 - (L)GPL3 или любая поздняя версия</li>
</ul>
</ul>
</li>
</li>
</ul>
</ul>
==Submitting packages to the AUR==
==Предоставление пакетов в AUR==
<p>Note the following before submitting any packages to the AUR:</p>
<p>Перед отправкой пакетов в AUR обратите внимание на следующее:</p>


<ol>
<ol>
         <li>
         <li>
                 The submitted PKGBUILDs '''MUST NOT''' build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference.
                 Представленные PKGBUILD '''НЕ ДОЛЖНЫ''' собирать приложения, уже находящиеся в любом из официальных бинарных репозиториев, ни при каких обстоятельствах. Исключением из этого строгого правила могут быть только пакеты, в которых включены дополнительные функции и/или исправления по сравнению с официальными. В этом случае массив pkgname должен быть другим, чтобы выразить эту разницу.
eg. A GNU screen PKGBUILD submitted containing the sidebar patch, could be named screen-sidebar etc. Additionally the '''provides=('screen')''' PKGBUILD array should be used in order to avoid conflicts with the official package.
Например. Пакет GNU screen PKGBUILD, содержащий патч sidebar, может быть назван screen-sidebar и т.д. Кроме того, массив '''provides=('screen')''' Массив PKGBUILD следует использовать чтобы избежать конфликтов с официальным пакетом.
         </li>
         </li>
<li>
<li>
To ensure the security of pkgs submitted to the AUR please '''ensure''' that you have correctly filled the {{ic|md5sum}} field. The {{ic|md5sum}}'s can be generated using the {{ic|updpkgsums}} command.
Для обеспечения безопасности пакетов, отправляемых в AUR, пожалуйста, '''убедитесь''', что вы правильно заполнили поле {{ic|md5sum}}. {{ic|md5sum}} можно сгенерировать с помощью команды {{ic|updpkgsums}}.
</li>
</li>
<li>
<li>
Please '''add a comment line''' to the top of the
Пожалуйста, '''добавьте строку комментария''' к верхней части файла {{ic|PKGBUILD}}, который следует этому формату.  Не забудьте замаскировать свой e-mail для защиты от спама:
{{ic|PKGBUILD}} file that follows this format.  Remember to disguise
                your email to protect against spam:


{{bc|# Maintainer: Your Name <address at domain dot com>}}
{{bc|# Maintainer: Ваше Имя <address at домен dot ru>}}


If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:
Если вы берете на себя роль сопровождающего для существующего PKGBUILD, добавьте свое имя в верхнюю часть, как описано выше, и измените имя предыдущего сопровождающего(их) на Contributor:


{{bc|# Maintainer: Your Name <address at domain dot com>
{{bc|# Maintainer: Ваше Имя <address at domain dot com>
# Contributor: Previous Name <address at domain dot com>}}
# Contributor: Предыдущее Имя <address at domain dot com>}}


</li>
</li>
<li>
<li>
Verify the package '''dependencies''' (eg, run
Проверьте ''зависимости'' пакета (например, запустите {{ic|lddd}} на динамических исполняемых файлах, проверить инструменты, требуемые скрипты и т.д.).
{{ic|ldd}} on dynamic executables, check tools required
by scripts, etc).


The TU team '''strongly''' recommend the use of the
Команда TU '''настоятельно''' рекомендует использовать утилиту {{ic|namcap}}, написанную Джейсоном Чу (jason@archlinux.org), для анализа вменяемости пакетов. {{ic|namcap}} предупредит вас о неправильных разрешениях, отсутствующих зависимостях, ненужных зависимостях, и других распространенных ошибках. Вы можете установить {{ic|namcap}} с помощью {{ic|pacman}}.
{{ic|namcap}} utility, written by Jason Chu (jason@archlinux.org), to analyze the
sanity of packages. {{ic|namcap}} will warn you about
bad permissions, missing dependencies, un-needed dependencies,
and other common mistakes. You can install the
{{ic|namcap}} package with {{ic|pacman}}.


Remember {{ic|namcap}} can be used to check both pkg.tar.gz files and PKGBUILDs
Помните, что {{ic|namcap}} можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD
</li>
</li>
<li> '''Dependencies'''
<li> '''Зависимости'''
are the most common packaging error. Namcap can help detect them, but
являются наиболее распространенной ошибкой при упаковке. Namcap может помочь обнаружить их, но он не всегда корректен. Убедитесь в наличии зависимостей, изучив исходную документации и на веб-сайте программы. </li>
it is not always correct. Verify dependencies by looking at source
<li>'''Не используйте {{Ic|replaces}}''' в PKGBUILD, если пакет не должен быть переименован, например, когда ''Ethereal'' стал ''Wireshark''. Если пакет является альтернативной версией уже существующего пакета, используйте {{Ic|conflicts}} (и {{Ic|provides}}, если этот пакет требуется другим). Основное различие: после синхронизации (-Sy) pacman немедленно хочет заменить установленный "нарушающий" пакет, если встретит пакет с соответствующим {{Ic|replaces}} где-либо в своих репозиториях; {{Ic|conflicts}}, с другой стороны, оценивается только при фактической установке пакета, что обычно является желаемым поведением, поскольку оно менее требовательно.</li>
documentation and the program website. </li>
<li>'''Do not use {{Ic|replaces}}''' in a PKGBUILD unless the package is to be renamed, for example when ''Ethereal'' became ''Wireshark''. If the package is an alternate version of an already existing package, use {{Ic|conflicts}} (and {{Ic|provides}} if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching {{Ic|replaces}} anywhere in its repositories; {{Ic|conflicts}} on the other hand is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.</li>
<li>
<li>
All files uploaded to the AUR should be contained in a '''compressed tar
Все файлы, загружаемые на AUR, должны содержаться в ''сжатом tar файле", содержащем каталог с '''{{ic|PKGBUILD}}''' и '''дополнительные файлы сборки''' (патчи, install, ...) в нем.
file''' containing a directory with the '''{{ic|PKGBUILD}}''' and '''additional build files''' (patches, install, ...) in it.
{{bc|foo/PKGBUILD
{{bc|foo/PKGBUILD
foo/foo.install
foo/foo.install
foo/foo_bar.diff
foo/foo_bar.diff
foo/foo.rc.conf}}
foo/foo.rc.conf}}
The archive name should contain the name of the package
Имя архива должно содержать имя пакета например, foo.tar.gz.
e.g. foo.tar.gz.


One can easily build a tarball containing all the required files by using {{Ic|makepkg --source}}. This
Можно легко собрать tarball, содержащий все необходимые файлы, используя {{Ic|makepkg --source}}. Это
makes a tarball named {{Ic|$pkgname-$pkgver-$pkgrel.src.tar.gz}}, which can then be uploaded to the AUR.
создает tarball с именем {{Ic|$pkgname-$pkgver-$pkgrel.src.tar.gz}}, который затем может быть загружен в AUR.
The tarball '''should not''' contain the binary tarball created by makepkg, nor should it contain the filelist
Тарбол '''не должен''' содержать бинарный тарбол, созданный makepkg, и не должен содержать список файлов
</li>
</li>


Latest revision as of 11:59, 22 February 2023

Other languages:
English • ‎русский

Представленные PKGBUILD ни при каких обстоятельствах не должны собирать приложения, уже находящиеся в официальных бинарных репозиториях. Исключением из этого строгого правила могут быть только пакеты с включенными дополнительными функциями и/или патчами по сравнению с официальными. В этом случае массив pkgname должен быть другим.

При создании пакетов для Manjaro Linux, придерживайтесь руководства по созданию пакетов, приведенного ниже, особенно если вы собираетесь внести свой вклад в новый пакет для Manjaro Linux. Вам также следует ознакомиться с PKGBUILD и makepkg manpages.

Прототип PKGBUILD

# Maintainer: Иван Иванов <ваша_почта@домен.ru>
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

    Такая ситуация противоречит эффективной функциональности AUR.

  • Избегайте использования /usr/libexec/ для для всего подряд. Вместо него используйте /usr/lib/${pkgname}/.
  • Поле packager из метафайла пакета может настраиваться создателем пакета путем изменения соответствующей опции в /etc/makepkg.conf файл, или альтернативно переопределить его, создав ~/.makepkg.conf
  • Все важные сообщения должны быть озвучены во время установки с помощью файла .install. Например, например, если пакет требует дополнительной настройки для работы, следует включить указания.
  • Любые необязательные зависимости, которые не нужны для запуска пакета или его общего функционирования, не должны быть включены; вместо этого информация должна быть добавлена в массив optdepends: 
    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')

    Приведенный выше пример взят для пакета wine в extra. Информация optdepends автоматически выводится при установке/обновлении, поэтому не следует хранить такую информацию в файлах .install.

  • При создании описания пакета для пакета не включайте имя пакета в виде самоссылки. Например, "Nedit is a text editor for X11" может быть упрощен до "A text editor for X11". Также старайтесь, чтобы описание не превышало ~80 символов.
  • Старайтесь, чтобы длина строки в PKGBUILD не превышала ~100 символов.
  • По возможности удаляйте пустые строки из PKGBUILD (provides, replaces и т.д.)
  • Общепринятой практикой является сохранение порядка полей PKGBUILD, как показано выше. Однако это необязательно, поскольку единственным требованием в данном контексте является правильный синтаксис bash.

Именование пакетов

  • Имена пакетов должны состоять только из буквенно-цифровых символов; все буквы должны быть строчными.
  • Имена пакетов НЕ должны иметь суффикс с номером версии основного выпуска 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/{pkgname}/, где {pkgname} - имя пакета (или подходящую альтернативу, например, apache использует /etc/httpd/).
  • Файлы пакетов должны следовать этим общим рекомендациям по каталогам:
/etc Системно-важные файлы конфигурации
/usr/bin Двоичные файлы
/usr/lib Библиотеки
/usr/include Файлы заголовков
/usr/lib/{pkg} Модули, плагины и тд.
/usr/share/doc/{pkg} Документация приложений
/usr/share/info Системные файлы GNU Info
/usr/share/man Страницы Man
/usr/share/{pkg} Данные приложений
/var/lib/{pkg} Постоянное хранение приложений
/etc/{pkg} Файлы конфигураций для {pkg}
/opt/{pkg} Большие самодостаточные пакеты, такие как Java и т.д.
  • Пакеты не должны содержать ни одного из следующих каталогов:
    • /dev
    • /home
    • /srv
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp
    • /run

Обязанности Makepkg

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

  1. Проверяет, установлены ли пакеты dependencies и makedepends.
  2. Загружает исходные файлы с серверов
  3. Проверяет целостность исходных файлов
  4. Распаковывает исходные файлы
  5. Применяет все необходимые патчи.
  6. Собирает программное обеспечение и устанавливает его в поддельный корень
  7. Удаляет символы из двоичных файлов
  8. Удаляет отладочные символы из библиотек
  9. Сжимает руководство и/или информационные страницы
  10. Генерирует мета-файл пакета, который включается в каждый пакет
  11. Сжимает поддельный корень в файл пакета
  12. Сохраняет файл пакета в настроенном каталоге назначения (cwd по умолчанию)

Архитектуры

Массив arch должен содержать 'i686' и/или 'x86_64' в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать 'any' для независимых от архитектуры пакетов.

Лицензии

Массив license внедряется в официальные репозитории, и его следует использовать и в ваших пакетах. Используйте его следующим образом:

  • В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL. Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=('GPL').
  • Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
    1. Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать: 
      install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    2. Если исходный tarball НЕ содержит сведений о лицензии, а лицензия отображается, например, только на сайте, то скопируйте лицензию в файл и включите его. Не забудьте также назвать его как-нибудь подходяще.
    3. Добавьте 'custom' в массив лицензий. По желанию вы можете заменить 'custom' на 'custom: "имя лицензии"'.
  • Как только лицензия используется в двух или более пакетах в официальном репозитории, включая [community], она становится общей
  • Лицензии MIT, BSD, zlib/libpng и Python являются особыми случаями и не могут быть включены в пакет 'common' пакета лицензий. Для переменной license они рассматриваются как обычные лицензии (license=('BSD'), license=('MIT'), license=('ZLIB') или license=('Python')), но для файловой системы это пользовательские лицензии, поскольку каждая из них имеет свою собственную строку копирайта. Каждый пакет с лицензией MIT, BSD, zlib/libpng или Python должен иметь свою уникальную лицензию, хранящуюся в /usr/share/licenses/$pkgname/.
  • На некоторые пакеты может распространяться не одна лицензия. В таких случаях в массиве лицензий может быть несколько записей, например license=("GPL" "custom:some commercial license"). Для большинства пакетов эти лицензии применяются в разных случаях, а не одновременно. Когда pacman получит возможность фильтрации по лицензиям (так что вы сможете сказать: "Мне нужны только программы с лицензиями GPL и BSD"), две (или более) лицензии будут рассматриваться pacman с использованием логики ИЛИ, а не И, поэтому pacman будет рассматривать приведенный выше пример как программу с лицензией GPL, независимо от других перечисленных лицензий.
  • У (L)GPL есть много версий и перестановок этих версий. Для программ под (L)GPL существует следующая концепция:
    • (L)GPL - (L)GPLv2 или любая поздняя версия
    • (L)GPL2 - только (L)GPL2y
    • (L)GPL3 - (L)GPL3 или любая поздняя версия

Предоставление пакетов в AUR

Перед отправкой пакетов в AUR обратите внимание на следующее:

  1. Представленные PKGBUILD НЕ ДОЛЖНЫ собирать приложения, уже находящиеся в любом из официальных бинарных репозиториев, ни при каких обстоятельствах. Исключением из этого строгого правила могут быть только пакеты, в которых включены дополнительные функции и/или исправления по сравнению с официальными. В этом случае массив pkgname должен быть другим, чтобы выразить эту разницу. Например. Пакет GNU screen PKGBUILD, содержащий патч sidebar, может быть назван screen-sidebar и т.д. Кроме того, массив provides=('screen') Массив PKGBUILD следует использовать чтобы избежать конфликтов с официальным пакетом.
  2. Для обеспечения безопасности пакетов, отправляемых в AUR, пожалуйста, убедитесь, что вы правильно заполнили поле md5sum. md5sum можно сгенерировать с помощью команды updpkgsums.
  3. Пожалуйста, добавьте строку комментария к верхней части файла PKGBUILD, который следует этому формату. Не забудьте замаскировать свой e-mail для защиты от спама: 
    # Maintainer: Ваше Имя <address at домен dot ru>

    Если вы берете на себя роль сопровождающего для существующего PKGBUILD, добавьте свое имя в верхнюю часть, как описано выше, и измените имя предыдущего сопровождающего(их) на Contributor: 

    # Maintainer: Ваше Имя <address at domain dot com>
# Contributor: Предыдущее Имя <address at domain dot com>
  4. Проверьте зависимости пакета (например, запустите lddd на динамических исполняемых файлах, проверить инструменты, требуемые скрипты и т.д.). Команда TU настоятельно рекомендует использовать утилиту namcap, написанную Джейсоном Чу (jason@archlinux.org), для анализа вменяемости пакетов. namcap предупредит вас о неправильных разрешениях, отсутствующих зависимостях, ненужных зависимостях, и других распространенных ошибках. Вы можете установить namcap с помощью pacman. Помните, что namcap можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD
  5. Зависимости являются наиболее распространенной ошибкой при упаковке. Namcap может помочь обнаружить их, но он не всегда корректен. Убедитесь в наличии зависимостей, изучив исходную документации и на веб-сайте программы.
  6. Не используйте replaces в PKGBUILD, если пакет не должен быть переименован, например, когда Ethereal стал Wireshark. Если пакет является альтернативной версией уже существующего пакета, используйте conflicts (и provides, если этот пакет требуется другим). Основное различие: после синхронизации (-Sy) pacman немедленно хочет заменить установленный "нарушающий" пакет, если встретит пакет с соответствующим replaces где-либо в своих репозиториях; conflicts, с другой стороны, оценивается только при фактической установке пакета, что обычно является желаемым поведением, поскольку оно менее требовательно.
  7. Все файлы, загружаемые на AUR, должны содержаться в сжатом tar файле", содержащем каталог с PKGBUILD и дополнительные файлы сборки (патчи, install, ...) в нем. 
    foo/PKGBUILD
foo/foo.install
foo/foo_bar.diff
foo/foo.rc.conf

    Имя архива должно содержать имя пакета например, foo.tar.gz.

    Можно легко собрать tarball, содержащий все необходимые файлы, используя makepkg --source. Это создает tarball с именем $pkgname-$pkgver-$pkgrel.src.tar.gz, который затем может быть загружен в AUR.

    Тарбол не должен содержать бинарный тарбол, созданный makepkg, и не должен содержать список файлов

Retrieved from "https://wiki.manjaro.org/index.php?title=Manjaro_Packaging_Standards/ru&oldid=47134"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.