Руководство по сопровождению пакетов

Это получает копию исходных кодов пакета с сервера. Это называется вашей «рабочей копией».

Это загружает любые исходные коды, хранящиеся в «lookaside cache» (см. ниже). Такие шаги, как fedpkg prep и fedpkg srpm, сделают это при необходимости, но вы можете захотеть получить копию сразу.

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

Извлечение исходных кодов, применение патчей и т.д. в каталоге рабочей копии:

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

Это простейший вид тестовой сборки, но обычно чище и лучше выполнять сборку в Mock или пробную сборку в Koji (см. ниже).

Это запускает сборку в Mock, если Mock настроен правильно. Использование Mock для тестирования сборки пакетов может в этом помочь.

Вы можете запросить пробную сборку в Koji (тестовую сборку, которая не попадёт в репозиторий) созданного .src.rpm с помощью команды koji build --scratch (см. man koji).

См. Пробные сборки в Koji.

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

Если вы хотите добавить некоторые ошибки rpmlint в белый список и предотвратить их появление, вы можете создать файл конфигурации rpmlint с именем <source_package_name>.rpmlintrc, и он будет применён.

По умолчанию Git не считает все файлы в рабочем каталоге частью репозитория (это удобно для хранения других связанных файлов, таких как дерево исходных кодов). Это говорит git начать рассматривать эти файлы как часть репозитория локально. Когда вы позже выполните commit и push, это изменение будет передано на сервер.

Заменить текущий список файлов исходных кодов.

Добавить к текущему списку файлов исходных кодов.

«Первозданные» исходные коды вышестоящего проекта (например, тарболлы релизов) и другие большие файлы исходных кодов хранятся в системе lookaside cache, а не фиксируются непосредственно в git. Это обеспечивает более эффективное хранение и передачу файлов. Файлы sources и .gitignore в репозитории синхронизируют его с lookaside cache.

Для загрузки файлов исходных кодов требуется действительный билет Kerberos. При каждой загрузке новых исходных кодов не забывайте фиксировать изменения в файле sources.

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

Эта команда извлекает запись из журнала изменений вашего пакета в файл clog, чтобы вы могли использовать его в качестве журнала изменений git, если захотите. Некоторые сопровождающие проводят различие между ними, некоторые — нет.

По умолчанию это ведёт себя как git commit -a: оно подготавливает изменённые файлы и фиксирует всё сразу, но не добавляет файлы, которые git ещё не отслеживает.

Это создаёт своего рода пакет, «коммит», ваших изменений в репозитории с уникальным идентификатором и журналом изменений. Другие сопровождающие — и вы сами позже — могут просматривать историю изменений в репозитории, где коммит является самым мелким уровнем детализации. Хорошей практикой является использование множества относительно небольших коммитов, каждый для одной цели. Не объединяйте увеличение версии с кучей исправлений пробелов и изменениями скриптов в одном коммите, создавайте отдельные коммиты для каждого.

Параметр -F clog будет использовать файл clog из предыдущего шага в качестве журнала изменений. -p выполнит push (см. ниже) одновременно с фиксацией. -c объединяет шаги clog и commit -F clog в один, если вам это нравится.

Это отправляет все новые коммиты из вашей локальной рабочей копии на вышестоящий сервер. Если вы всё ещё изучаете систему, сейчас самое время выполнить fedpkg co другой копии репозитория в другом месте, сравнить то, что вы получили, с вашей рабочей копией и выполнить на ней тестовую сборку.

Подробности см. в Сборка слоёных образов контейнеров.

В отличие от большинства вышеперечисленных команд, эта работает с состоянием, которое вы отправили в git, а не с локальным состоянием. Если у вас возникли проблемы, убедитесь, что вы отправили и зафиксировали все патчи и правильно обработали исходные коды.

См. Обновление взаимозависимых пакетов, если вы вносите взаимозависимые изменения в несколько пакетов.

Эта команда запросит ветку git для Fedora 42.

Эта команда запросит ветки git для каждого активного в данный момент выпуска Fedora.

Эта форма может использоваться для запроса веток, когда вы не находитесь внутри Git-репозитория пакета. Вам не нужно ждать создания репозитория перед подачей такого запроса на ветку, но вы должны запросить репозиторий перед запросом веток.

Эта команда запросит ветку git для EPEL 9.

Некоторые пакеты нужны только для EPEL. Для таких пакетов после создания репозитория ветка rawhide '''должна''' быть удалена. Используйте следующую команду (с переключением на ветку rawhide):

Вы можете поддерживать каждую ветку полностью отдельно, если хотите, кропотливо копируя изменения между ними (при условии, что вы всегда остаётесь в рамках требований Политики обновлений). Однако git предоставляет нам несколько удобных инструментов для работы с ветками. Вот пример:

Это слияет изменения из ветки rawhide в ветку f42. Знатоки git могут заметить, что это несколько необычный рабочий процесс, но он подходит для контекста управления пакетами. Помните, что после отправки и сборки для стабильного выпуска или ветвлённого релиза после активации updates-testing, вам необходимо будет отправить обновление, прежде чем другие пользователи Fedora увидят вашу сборку.

Обратите внимание, что слияние будет работать чисто только до тех пор, пока ветки ранее не расходились. То есть, если вы сделаете это:

вы можете столкнуться с конфликтом слияния.

Помните, что git — это совместная система, и она используется именно так в управлении пакетами Fedora. Часто бывает так, что вы должны учитывать изменения, внесённые другими при работе над пакетом, и думать о том, как ваши изменения повлияют на других.

Это обширная тема и несколько выходит за рамки данного руководства, но мы можем дать основные указания. Есть другие хорошие источники в книге о Git и в документации GitHub.

Когда вы выполняете слияние и возникает конфликт, вы можете отредактировать файлы, в которых есть конфликты. Удалите маркеры конфликтов в файлах и объедините изменения вручную. Используйте git diff или fedpkg diff, чтобы проверить изменения по сравнению с состоянием до конфликта и убедиться, что вы удовлетворены разрешением. Затем вы можете зафиксировать файлы с помощью fedpkg commit или git commit -a. Git определит, разрешили ли вы конфликт, проверив, что все маркеры конфликтов удалены.

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

Если вы используете команды git для создания веток и получения их напрямую, вы можете определять любые локальные имена веток. Если вы используете fedpkg switch-branch, по умолчанию будут создаваться имена, используемые в примерах выше.

Часто полезно знать, в какой ветке вы работаете, с первого взгляда. Вы можете добавить эту информацию в приглашение bash с помощью информации здесь.

Вот сценарий: вы успешно собрали свой пакет в ветке f42, но есть проблема, мешающая сборке пакета в last.

Решение: Внесите изменения в ветку, а затем добавьте цифру в самый конец тега выпуска. Нет необходимости изменять выпуск в других ветках. Это позволяет обновлениям работать гладко, если пользователь обновляется до более нового выпуска Fedora.

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

Время от времени вам может потребоваться удалить сборку пакета, которую вы отправили в Rawhide или в Branched до заморозки Alpha (в обоих случаях сборка обычно попадает в основной репозиторий без дальнейшей проверки). Это может произойти, если в вашем пакете обнаружена ошибка или проблема, которая будет исправлена вышестоящим проектом в следующем выпуске, или вы понимаете, что допустили значительную ошибку в сборке, которую нелегко исправить.

Вы можете удалить пакет с помощью Koji:

где foo-1.1.3-1.fc43 заменяется на имя вашей сборки пакета. См. koji help или Использование системы сборки Koji для получения дополнительной информации.

Рекомендуемый вариант — добавить VerifyHostKeyDNS yes в ваш файл ~/.ssh/config. Это приведёт к использованию DNS для проверки правильности ключа.

Но вы также можете вручную проверить по списку ключей на Fedora Apps. Строки там попадают в ваш файл ~/.ssh/known_hosts. Поэтому вы можете принять отпечаток при запросе, а затем проверить, что правильная строка для src.fedoraproject.org попала в ваш файл ~/.ssh/known_hosts.

Инструмент fedpkg клонирует репозитории с использованием протокола ssh://, поэтому обычно это не должно быть проблемой (при условии, что у вас есть ключ ssh). Если вы клонировали с помощью самой утилиты git, проверьте файл .git/config, чтобы убедиться, что доступ к удалённому репозиторию осуществляется через протокол ssh://, а не git://.

Отправка в ваш форк-репозиторий через http может завершиться ошибкой: