Трохи про arch user repository

Отже, Arch User Repository (AUR або АУР) - це репозиторій, підтримуваний і розвивається практично виключно спільнотою Archlinux. Є ще окремі люди, звані довіреними користувачами (TU), на плечах яких лежить своєрідна "модерація" цього сховища. На мій скромний погляд, чи не єдина відмінність Archlinux від інших дистрибутивів - це наявність AUR'а. Відмінність цього сховища від звичайних перш за все в тому, що він не містить архівів з кодами або зібраних пакетів - тільки скрипт збірки (PKGBUILD) і, можливо, додаткові текстові файли.

Звичайно, вручну завантажувати архів з сайту AUR'а, а також перевіряти оновлення, не зовсім зручно, тому існує набір хелперів. Більшість хелперів є обгортку над pacman. Я виділю тільки два - packer - мінімалістичний, зручний, швидкий - і yaourt - на короби, але зате більш функціональний. За не дуже зрозумілим мені причин, в російськомовному сегменті більшого поширення отримав yaourt, за кордоном - packer.

Крім хелперів, існують також консольні клієнти для роботи з AUR. Я виділю, мабуть, тільки один - python-aur. Іноді зручна альтернатива веб-інтерфейсу.

Інша особливість даного сховища - і не менш важлива - всі дії з ним здійснюються на свій страх і ризик. Небезпечні і некоректні пакети, звичайно ж, видаляються, але цілком можуть бути і помилки при складанні і ще все, що зможете придумати. Дик от - робота з ним на вашій совісті, і ніхто вам нічого не винен, якщо щось зламається. З цієї ж причини, жоден хелпер в доступному для огляду майбутньому не буде перенесений в офіційні репозиторії.

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

Установка з AUR

Завантаження пакету в AUR

Ніяких makepkg -S. З недавніх пір даний метод вважається застарілим. Але про все по-порядку

Нам потрібно завантажити архів на сайт. У цьому архіві повинні бути PKGBUILD і .AURINFO. З приводу першого я розповім ще трохи нижче, другий генерується автоматично. Також, там можуть бути установчі скрипти (* .install), патчі, файли ліцензії (якщо не надаються апстрімом з кодами), сервіси systemd, скрипти запуску - це те, що зазвичай включено. Ніяких початкових кодів. І тим більше ніяких бінарників. (Жарти-жартами, а я пам'ятаю пакет, в якому вихідний код записувався за допомогою cat <

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

Кілька правил завантаження пакета в AUR:

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

супровід пакетів

Список розсилки AUR

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

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

Будь ласка, пишіть листи в список розсилки акуратно. І, бажано, ввічливо (а то потім будете генерувати щось на кшталт такого) (ми всі знаємо, що ми Арче-школярі, не треба нас ще раз цим тикати, ми образимося). Також намагайтеся уникати надмірного цитування. І - це практично вимога - надавайте посилання на пакети. Хороший варіант - складання списку посилань в кінці листа, а в тілі посилатися на них таким чином [1]. Якщо не впевнені в правильності запиту - подивіться архів списку розсилки.

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

змінні PKGBUILD

Основні змінні такі:

Всі перераховані вище змінні вказуються в заголовку 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 може виглядати так:

pkgbase взагалі зручна штука. Наприклад, для створення пакетів одночасно для двох версій Python PKGBUILD може виглядати приблизно так. Або, в загальному випадку, як-то так.

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

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

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