Сборка пакетов/Соглашение по стилю RPM-пакетов/Список изменений

Материал из openSUSE.

Список изменений RPM(changelogs)

Данный раздел описывает политику ведения списка изменений (changelogs) RPM. Эта политика не затрагивает список изменений распространяющийся вместе с исходным кодом.

Главное помнить, о том что список изменений RPM будут читать не только хорошо информированные разработчики, но и обычные пользователи (с небольшими навыками администрирования), и даже по прошествии 1-2 лет должна быть возможность вернуться к предыдущим spec-файлам (за исключением случаев, когда для этого нужны удаленные патчи).

Записи в списке изменений располагаются в хронологическом порядке. Не разрешается изменение предыдущих записей если пакет прошел начальную проверку (в buildservice) и уже отправлен в автосборку.

Основная информация

• openSUSE использует отдельный файл для списка изменений. Этот файл называется также как .spec файл, но с расширением .changes.
• записи в .changes файле имеют следующую структуру:

-------------------------------------------------------------------
Tue Apr 22 20:54:26 CEST 2008 - your@email.com

-

Новая запись начинается с 67 знаков разделителя '-' На следующей строке идет текущая дата в POSIX формате, разделитель отделенный пробелами и e-mail адрес отвечающего за сборку пакета Третья линия - пустая Каждое изменение начинается со знака '-', вы также можете использовать другие разделители для группировки пакетов Последняя строка также пустая.

При установке пакета 'osc', устанавливается утилита buildvc, которая может быть использована для создания правильной записи для .changes файла.

Номера ошибок в списке изменений

В процессе поддержки дистрибутива, каждое изменение должно быть отмечено корректным номером ошибки. Обычно это номер с сайта https://bugzilla.novell.com/. При этом обычно указывают и краткое описание ошибки.

Например:

- Removed invalid desktop Category "Application" (bnc#254654).
- Symlink icon to pixmaps dir (bnc#152108)
- Added gnome-ui-properties to control-center (bnc#118960#c11).

Между сокращением(трекера ошибок) и номером ошибки нет символов пробела.

Чтобы избежать путаницы и двойной работы, разрешены ссылки и на другие трекеры ошибок(bugzillas). Ниже представлен список сокращений для часто используемых трекеров ошибок, которые должны находится перед символом "#" в идентификаторе ошибки:

Для других трекеров ошибок используйте полные URL-адреса, вместо номеров ошибок. Пример:

• http://developer.berlios.de/bugs/?func=detailbug&bug_id=12707&group_id=769

Номера ревизий CVE в списке изменений

Также как и с номерами ошибок: добавьте короткое описание к ревизий CVE (обычно используют CVE-сводку новшеств ).

Примеры:

- Add gdk-pixbuf-226710.patch (#226710, and CVE-2007-0010).
- More XPM fixes: CVE-2005-2975 xpm too many colors DoS (#129642)
- fix ~/.dmrc symlink attack (#180704, CVE-2006-2449)

Изменения .spec файла

Будьте точны, насколько это вообще возможно! Это тем более важно, если вы удаляете что-либо из .spec файла.

• Удаление строк из оригинального .spec файла должны быть отражены в списке изменений с комментарием (например: "useful for FreeBSD only") - нет необходимости дублировать это в .spec файле.
• Дополнительные команды (например в разделе %install) и краткие комментарии к ним - это так же следует добавить в список изменений.
• Добавление/удаление пакетов в тегах Requires/Provides должно быть отражено в списке изменений.

Изменения в исходном коде

В список изменений можно добавить наиболее важные изменения в исходном коде, но только очень кратко.

• Просмотри список изменений проекта, и в первую очередь укажите изменения важные для данного дистрибутива (изменения для других ОС - не важны). Что изменилось в новой версии, обычно достаточно просто просмотреть файл NEWS, поскольку полный список изменений - очень длинный. Для обзора наиболее важных изменений, не стоит использовать более 10-15 строк.

Что изменилось в новой версии, как правило, в уровне детализации НОВОСТИ файлов, изменений файлы обычно слишком долго. Более 10-15 строк не должно быть необходимым для описания наиболее важных изменениях.

• arrange the original changes behind the version update information.

Пример:

 - Update to 1.3.2:
   + fixes memory leak in import function
   + new API command: unlock_client()
   + the following bugs are closed by this new upstream release:
   ++ ............ [MGN:332]
   ++ .............[MGN:337]
 - split of devel package

• If upstream does not provide a meaningful changelog, then only do best effort. Don't waste too much time over it. See [[1]] for a discussion on best practises.
• If the upstream tarball really has not changed except for the version number, just the version number in the changelog would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consist of "updated translation" or "several bugfixes" even that can be sufficient for a changelog entry (unless these bugfixes contain something you find worth mentioning).