Використання Devtools в Arch Linux

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

Зверніться до цього посібника, щоб зрозуміти та використовувати AUR в цілому, включаючи отримання PKGBUILD. У цьому документі показано лише кроки, характерні для Devtools, якщо це спосіб, який ви вибрали для компіляції пакета.

Devtools підтримує окрему чисту інсталяцію Arch, розташовану в /var/lib/archbuild/<TARGET>/root, яка містить лише групи пакетів baseі base-devel. Якщо цієї чистої інсталяції не існує, вона автоматично створює її. Якщо він існує, він автоматично оновлює всі пакунки в ньому. Коли для створення пакету використовується Devtools, він починається з копії цієї чистої інсталяції, встановлює необхідні пакунки лише в копію, копіює в неї вихідний код, виконує компіляцію та пакування в ньому та копіює лише отриманий пакет, в ідентичній формі з того, що знаходиться в офіційних сховищах.

У Devtools є переваги перед прямим запуском makepkg. Однією з переваг є те, що base-develта інші пакунки, необхідні для компіляції, але не запуску, пакет, який ви створюєте, ніколи не потрапляє у вашу основну систему. Це менше пакетів, які потрібно періодично оновлювати, і щодо них є занепокоєння. Хоча в першу чергу цей процес є перевагою для супроводжувачів пакетів Arch, цей процес легко виявляє, коли a PKGBUILDє неправильним, наприклад, якщо в списку пропущена залежність, яку супроводжувач вже інстальовано в їхній основній системі. Ви також можете використовувати машину, яка швидше збирає пакети, і скопіювати отриманий пакет на більш повільну машину, яка буде запускати його, не забруднюючи установку будівельної машини.

Основним недоліком є ​​те, що чистий корінь завжди є, займаючи близько 800 МБ, і зазвичай одна копія там займає більше місця. Зауважте, що якщо /var/lib/archbuild/використовується Btrfs, копія чистого кореня починає бути знімком Btrfs, тому ці файли не займають подвійний простір. Чистий корінь завжди зберігається там, щоб уникнути його повторної інсталяції щоразу, коли створюється пакет.

Компіляція за допомогою Devtools

Встановіть Devtools:

# pacman -S devtools

Щоб створити пакет, Devtools включає archbuild, але ви не запускаєте його безпосередньо. Він також містить символічні посилання {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. Символьне посилання, яке використовується для запуску, буде перевірено archbuild, щоб визначити, яку ціль ви хочете використовувати. Його можна запустити, щоб використовувати ці нестабільні/стабільні/тестові репозиторії, які можуть мати новіші версії, ніж були випущені в офіційні репозиторії. Щоб використовувати офіційні репозиторії для пакунків, які не належать до AUR, у каталозі з PKGBUILD, наприклад каталогом, створеним git clone, запустіть наступне:

$ extra-x86_64-build

Примітка . Решта цього посібника буде просто посилатися на extra-x86_64-build.

Після його завершення будуть результати:

• /var/lib/archbuild/extra-x86_64/root- Чистий chroot , який є сучасною інсталяцією лише з групами пакетів baseі base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- Це буде містити збірку chroot . Це копія чистого chroot з будь-якими залежностями, необхідними для створення або запуску пакунка, що збирається, а також його вихідний код, результати компіляції та пакет.
• Каталог, у якому ви перебуваєте, міститиме файли журналів пакетів і збірок, а також будь-який завантажений вихідний код.

Наприкінці ви можете помітити " Checking PKGBUILD" і " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz". Будь-які рядки після них виводяться з namcap, який автоматично шукає такі проблеми, як неправильно сформовані PKGBUILDфайли, включені залежності, які, здається, не використовуються, залежності не включені, які, здається, використовує пакет, тощо. Помилкові спрацьовування часто генеруються namcap, але це чудовий інструмент для того, щоб дати речі для розслідування. Якщо ваш пакунок працює правильно, не варто сповіщати супроводжувача про namcapвихід, якщо ви не перевірили його та не переконалися, що потрібно внести зміни.

Ви можете використовувати pacmanдля встановлення пакунка, який встановить будь-які залежності, необхідні для запуску пакунка, якщо вони знаходяться в офіційних сховищах або локальному сховищі.

Або використовуйте локальний репозиторій, як описано тут , або встановіть файл безпосередньо:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

Якщо ви запустите extra-x86_64-buildзнову, прямо зараз або в будь-який час пізніше з цим чи іншим пакетом, він оновить чистий chroot, якщо потрібно, видалить збірку chroot і зробить його свіжою копією чистого chroot, і виконає той самий процес. Якщо у вашому каталозі все ще є вихідний код, завантажений з останнього разу, він використовуватиме його. Якщо пакет є пакетом AUR для розробки, він буде вносити нові зміни, а не повторно клонувати.

Внутрішньо extra-x86_64-buildвиконує makechrootpkg, який внутрішньо викликає makepkg. Варіанти extra-x86_64-buildвключають наступне:

• -c: Очистіть chroot, видаливши та повторно створивши весь /var/lib/archbuild/extra-x86_64/каталог, включаючи його чистий chroot та всі каталоги chroot збірки. Це рідко потрібно, лише якщо чистий chroot пошкоджено, або якщо Devtools оновлено таким чином, що порушує зворотну сумісність.
• -r <dir>: Використовуйте інший каталог, ніж /var/lib/archbuild/extra-x86_64/для chroot.

Будь-які аргументи extra-x86_64-buildafter --передаються до makechrootpkg, коли він внутрішньо використовує його. Кілька аргументів завжди автоматично передаються з extra-x86_64-buildдо makechrootpkg. Ці автоматичні аргументи є -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n. Вони кажуть makechrootpkgвидалити збірку chroot і зробити її свіжою копією чистого chroot, а також запустити namcapпакунок, якщо він успішно змонтується. Часто використовуваним параметром, який можна передати, makechrootpkgє -l <copy name>. Це ім’я каталогу для створення chroot замість <USERNAME>, що корисно для підтримки кількох копій або компіляції кількох пакетів одночасно.

Будь-які аргументи makechrootpkgafter --передаються до makepkg, коли він внутрішньо використовує його для створення пакунка. Перший раз makepkgзапускається makechrootpkg, це робиться з власними незмінними параметрами, щоб завантажити вихідні файли, якщо потрібно, і виконати перевірку цілісності; таким чином, нічого не можна переслати під час цього прогону. Він запускається makepkgвдруге, щоб створити пакет, і завжди автоматично передає makepkgаргументи, --syncdeps --noconfirm --log --holdver --skipintegякі вказують, makepkgщоб у межах збірки chroot автоматично встановлювати відсутні залежності, необхідні для створення та використання пакунка, не запитувати підтвердження під час pacman, реєструвати процес збірки у текстовому вигляді файли на додаток до stdout, не оновлюйте вихідний код у системі контролю версій і не перевіряйте вихідний файл.

Ви можете об’єднати їх разом, використовуючи таку форму:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

Зауважте, що /var/lib/archbuildце можна розглядати як тимчасовий каталог. Якщо у вас є кілька жорстких дисків Vultr, варто змонтувати сюди файлову систему RAID0 (смуг). Якщо у вас багато оперативної пам’яті, ви також можете підключити файлову систему з підтримкою RAM, наприклад tmpfs. Після створення пакунка він копіюється в каталог, з якого ви запускали, extra-x86_64-buildі, якщо хочете, на цьому етапі ви можете видалити файл /var/lib/archbuild. Наступний запуск буде повільнішим, тому що потрібно створити новий чистий корінь. Крім того, ви можете видалити, /var/lib/archbuild/<USERNAME>щоб повернути додатковий простір у збірці chroot, перш ніж він буде автоматично видалено наступним запуском Devtools. Таким чином, навіть якщо у вас змонтована тут файлова система RAID0 виявиться збій, ви втратите найбільше – це компіляція в процесі.

Файли конфігурації Devtools

З файлами конфігурації Devtools слід звернути увагу на деякі особливості. Вони розташовані в /usr/share/devtools/, таких як makepkg-x86_64.confі pacman-extra.conf:

• Для /etcфайлів, як makepkg.confі pacman.conf, ви можете безпечно редагувати їх на місці, і коли пакет буде оновлено, він не перезапише ваші зміни. Натомість він збереже нові файли конфігурації (якщо вони змінилися порівняно з попередньою версією), які закінчуються на .pacnew. Однак файли конфігурації Devtools /usr/share/не призначені для редагування користувачами, тому під час оновлення Devtools повністю перезапише ваші зміни в цих файлах без попередження. Зміна цієї поведінки була запропонована та відхилена, оскільки це допомагає гарантувати, що пакунки надсилаються в офіційні репозиторії з однаковими налаштуваннями компіляції.
• Значення для MAKEFLAGS, PACKAGER, і {SRC,SRCPKG,PKG,LOG}DESTберуться з, /etc/makepkg.confа не з /usr/share/devtools/makepkg-x86_64.conf.

Локальний репозиторій

Якщо ви створюєте пакунки, які залежать від інших створених вами пакунків, вам потрібно використовувати локальне сховище, щоб під час виконання pacmanв chroot збірки він знаходив залежності.

Щоб налаштувати локальне сховище, зверніться до розділу «Локальне сховище» цього посібника .

Створіть спеціальну ціль:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

Відредагуйте /usr/share/devtools/pacman-custom.confта додайте наступне в кінці:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Відредагуйте /etc/pacman.confта додайте наступне. Це змушує каталог підключатися до chroot:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

Тепер замість використання extra-x86_64-buildвикористовуйте це:

$ custom-x86_64-build

Якщо ви завжди хочете використовувати користувальницьке цільове призначення, ви можете видалити /var/lib/archbuild/extra-x86_64-build/каталог, якщо він існує, оскільки chroot тепер буде в /var/lib/archbuild/custom-x86_64-build/.

Пакуйте швидше

Зауважте, що увімкнення потокового пакування передбачає редагування /usr/share/devtoolsфайлів конфігурації, яке офіційно не підтримується, тому вам потрібно буде виконувати цю зміну щоразу, коли Devtools оновлюється.

Devtools об’єднує весь пакет у формат архіву. За замовчуванням він .tar.xzвикористовує один потік для xzстиснення.

У системах з кількома процесорами ви можете дозволити xzвикористовувати кілька потоків, відредагувавши /usr/share/devtools/makepkg-x86_64.conf, і змінивши наступний рядок:

COMPRESSXZ=(xz -c -z -)

Щоб дозволити стільки потоків, скільки у вас віртуальних ядер:

COMPRESSXZ=(xz -c -z - --threads=0)

Щоб дозволити використовувати кілька віртуальних ядер, але не всі з них, щоб зменшити вплив на загальну продуктивність системи, додайте конкретну кількість:

COMPRESSXZ=(xz -c -z - --threads=21)

Якщо вказати більше потоків, ніж кількість наявних у вас віртуальних ядер, це знизить продуктивність.

Якщо ви не проти того, що файл пакету (потенційно набагато) більший, вимкніть стиснення, відредагувавши /usr/share/devtools/makepkg-x86_64.conf, і змініть наступний рядок:

PKGEXT='.pkg.tar.xz'

Змініть його, щоб він виглядав так:

PKGEXT='.pkg.tar'