Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Git-пакеты (с суффиксом -git в имени) собираются не из релизного архива, а прямо из git-репозитория проекта, обычно из master-ветки. Обновляются они сами: при каждом yay -Syu помощник заново вычисляет версию из последнего коммита, и если появились новые коммиты — пересобирает пакет. Ломаются они чаще обычных, потому что master у апстрима не обязан быть стабильным. Разберём механику по шагам.
Обычный пакет в репозиториях Arch собирается из зафиксированного релиза. Разработчик выпустил версию 1.2.3, пакет собрали из архива с этим тегом, и версия в PKGBUILD прописана руками. Git-пакет вместо этого клонирует репозиторий и собирает то, что лежит в master (или в другой ветке) прямо сейчас.
В имени пакета суффикс -git — это сигнал: версия не фиксирована, пакет «плавает» вместе с апстримом. Примеры: hyprland-git, neovim-git, yay-git.
Живут такие пакеты в основном в AUR: в официальных репозиториях Arch git-сборок почти нет, потому что их нельзя протестировать заранее. Каждый раз, когда ты ставишь -git пакет, ты собираешь его у себя на машине — это не готовый бинарник, а результат компиляции из свежего исходника.
В PKGBUILD у такого пакета нет обычного pkgver=1.2.3. Вместо этого есть функция pkgver(), которая вычисляет версию из состояния репозитория. Про устройство PKGBUILD целиком — в статье «Свой PKGBUILD: полный гайд».
Кстати, у git-пакетов есть и pkgrel — номер ревизии PKGBUILD. Его поднимают, когда меняется сам PKGBUILD (добавили зависимость, поправили флаги сборки), даже если версия исходников не выросла.
Механика простая. При сборке makepkg клонирует репозиторий (или обновляет уже склонированный), затем вызывает pkgver(). Функция смотрит на последний коммит и формирует версию. Дальше makepkg сравнивает новую версию с установленной: версия выросла — пакет пересобирается и ставится.
Как выглядит pkgver() на практике:
pkgver() {
cd "$srcdir/$pkgname"
git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}
git describe --long --tags берёт ближайший тег, считает коммиты после него и добавляет хеш последнего коммита. Получается что-то вроде 1.2.3.r14.g8f3a2b1: версия 1.2.3 плюс 14 коммитов после неё.
Есть и другие способы посчитать версию:
git rev-list --count HEAD # просто число коммитов
git log -1 --format=%cd --date=short # дата последнего коммита
Какой бы способ ни выбрал автор PKGBUILD, суть одна: версия растёт с каждым новым коммитом.
Когда ты запускаешь yay -Syu, помощник для каждого git-пакета заново обновляет репозиторий, вычисляет pkgver и сравнивает с установленной версией. Есть новые коммиты — версия больше — пакет пересобирается. Нет — пропускает. Поэтому git-пакеты обновляются сами, без ручного вмешательства. Про разницу между yay и paru — в статье «yay vs paru: какой безопаснее».
Важный нюанс: пересборка происходит, когда меняется версия пакета целиком. Выросла pkgver — пересборка. Вырос только pkgrel — тоже пересборка. Ничего не изменилось — помощник пропустит пакет.
yay и paru проверяют git-пакеты при каждом -Syu по умолчанию. Если нужно обновить только AUR, не трогая официальные репозитории, — yay -Sua --devel.
Сам процесс выглядит так: помощник показывает список обновлений, ты подтверждаешь, makepkg клонирует репозиторий, компилирует, упаковывает, и pacman ставит готовый пакет. Время сборки зависит от проекта: маленькая утилита соберётся за минуту, большой проект вроде редактора — за десять.
Если сборка во время -Syu упала, помощник пропустит пакет и продолжит обновление остальных. Система останется на старой версии git-пакета — это не страшно, но имей в виду: причину поломки ты увидишь только в логе сборки.
Проверить, что реально собралось, можно так:
pacman -Q hyprland-git
# hyprland-git 0.41.2.r14.g8f3a2b1-1
Версия в выводе показывает, из какого коммита собран пакет. Сверить с текущим состоянием репозитория:
git -C ~/builds/hyprland-git/src/hyprland-git log --oneline -1
Сборка из master — это сборка из незафиксированного состояния. Ломаться тут есть где.
Сломан master у апстрима. Разработчик закоммитил недоделанное, ты собрал — и получил ошибку компиляции. Релизы так не страдают: их выпускают, когда код стабилен.
Изменились API или зависимости. Проект перешёл на новую библиотеку, а PKGBUILD в AUR ещё не обновили. Или наоборот: PKGBUILD обновили, а зависимость в репозиториях не подъехала.
Поменялось окружение сборки. Обновился компилятор, подъехала новая версия библиотеки, изменился сам makepkg — и вчерашний PKGBUILD сегодня не собирается. Релизные пакеты от этого защищены: их пересобирают мейнтейнеры и проверяют перед публикацией.
pkgver считается неправильно. Автор PKGBUILD взял git describe, но тегов в репозитории нет или они не совпадают с релизами. Тогда версия не растёт, помощник не видит обновлений, и пакет «застревает» на старом коммите.
Зависимость из AUR тоже git-пакет. Если git-пакет тянет другой git-пакет, поломка одного ломает всю цепочку: обновления приходят вразнобой, и собрать связку получается не всегда.
Сборка нестабильна сама по себе. Компиляция проходит, но программа падает: в master сломали что-то, что не ловится на этапе сборки.
Сначала определи, где именно ломается. Запусти сборку вручную:
yay -S hyprland-git
или напрямую через makepkg:
git clone https://aur.archlinux.org/hyprland-git.git
cd hyprland-git
makepkg -si
Ошибка на этапе клонирования — проблема с сетью или с самим репозиторием. Ошибка компиляции — смотри последние строки вывода: там будет имя файла и причина. Про чтение вывода makepkg — в статье «makepkg: всё, что нужно знать».
Если сборка падает на тестах, попробуй makepkg --nocheck — пропустить тесты и собрать только код. Это не лечение, но помогает понять: сломан код или тесты.
Дальше по ситуации.
Сломан master. Зафиксируйся на последнем рабочем коммите. В PKGBUILD можно указать конкретный коммит прямо в source:
source=("$pkgname::git+https://github.com/author/project.git#commit=8f3a2b1")
Устарел PKGBUILD. Проверь, не появилась ли свежая версия в AUR. Если нет — обнови зависимости в PKGBUILD сам или подожди автора. Перед тем как чинить самому, загляни в комментарии к пакету на странице AUR: часто там уже описан обходной путь или указано, что автор в курсе и готовит фикс.
Версия не растёт. Посмотри, что выдаёт pkgver():
cd src/hyprland-git
git describe --long --tags
Если тегов нет — функция вернёт мусор. Тогда версию считают по числу коммитов или по дате.
Хочешь пересобрать без повторного клонирования. Исходники лежат в каталоге сборки, обычно ~/builds/<пакет>/src/. makepkg -e пересоберёт пакет из уже скачанных исходников, makepkg -o только скачает и распакует их без компиляции, а makepkg -c полностью почистит каталог сборки.
Хочешь стабильности. Перейди на релизную версию из репозитория: pacman -S hyprland вместо hyprland-git. Откат к прошлой версии пакета — через кэш pacman или архив, как в статье «Откат пакетов из архива Arch».
Git-пакеты оправданы, когда:
Для повседневной системы это компромисс: ты получаешь новое раньше всех, но платишь нестабильностью. На production-машинах git-пакеты лучше не держать: обновление может прийти в любой момент и сломать сервис. Если git-пакет нужен, но хочется контроля — зафиксируй коммит в PKGBUILD и обновляй вручную, когда сам решишь.
Сравнение простое: релизная версия из репозитория — это проверенный тег, git-версия — это «сейчас» из master. Для рабочей машины, где важна предсказуемость, бери релиз. Для экспериментов и разработки — git.
И ещё один момент: git-пакеты не участвуют в официальном тестировании, поэтому обновление может прийти в любой день, а не по расписанию релизов.
Скорее всего, pkgver не растёт: в репозитории нет тегов, или git describe возвращает одну и ту же строку. Проверь вручную, что выдаёт pkgver(), и посмотри, есть ли новые коммиты в клоне.
Откати пакет на прошлую версию из кэша pacman или архива, затем либо зафиксируй рабочий коммит в PKGBUILD, либо перейди на релизную версию.
Релизная версия собрана из зафиксированного тега и протестирована. Git-версия собрана из текущего состояния master: она новее, но никто не гарантирует, что она работает.
Нет, они конфликтуют: оба ставят одни и те же файлы. Выбирай что-то одно.
Автор PKGBUILD поднял pkgrel — номер ревизии пакета. Его меняют, когда правят сам PKGBUILD: добавили зависимость, поправили флаги сборки. Версия исходников не выросла, но ревизия пакета изменилась, поэтому помощник пересобирает.
Git-пакеты — это сборка из живого master вместо зафиксированного релиза. Обновляются они сами: pkgver растёт с каждым коммитом, и помощник пересобирает пакет при -Syu. Ломаются они чаще обычных, потому что master не обязан быть стабильным. Если пакет сломался — зафиксируй рабочий коммит, обнови PKGBUILD или перейди на релизную версию. Для экспериментов и разработки git-пакеты удобны, для production — риск.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии