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

Перейти к: навигация, поиск
11. Список изменений RPM

Назад



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


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

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

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


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


  • openSUSE использует отдельный файл для списка изменений. Этот файл называется также как .spec файл, но с расширением .changes.
  • записи в .changes файле имеют следующую структуру:
-------------------------------------------------------------------
Tue Apr 22 20:54:26 CEST 2008 - your@email.com

-

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

При установке пакета '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 трекера ошибок Пример
CVE записи(пожалуйста добавляйте номер, даже если для этого есть дополнительные трекеры ошибок) http://cve.mitre.org (CVE-2009-0067)
Fate (трекер для запроса новых возможностей) https://features.opensuse.org/ (fate#1234)
GCC http://gcc.gnu.org/bugzilla/ (GCC#3321)
GNOME http://bugzilla.gnome.org/ (bgo#4432)
KDE http://bugs.kde.org/ (KDE#121114)
Kernel или K http://bugzilla.kernel.org/ (Kernel#8123) или (K#8123) или (bko#8123)
Launchpad (Ubuntu) https://bugs.launchpad.net/ (bln#236378)
Mono http://bugzilla.ximian.com/ (Mono#1234)
Mozilla http://bugzilla.mozilla.org/ (bmo#1234)
Novell https://bugzilla.novell.com/ (bnc#1234)
OpenOffice.org (Issuezilla) http://qa.openoffice.org/issues/ (i#1234)
OpenOffice.org Novell (obsolete) https://bugzilla.novell.com/ (n#1234)
openSUSE-Education http://devzilla.novell.com/education/ (os-edu#1234)
RedHat https://bugzilla.redhat.com/ (rh#1234)
Samba https://bugzilla.samba.org/ (bso#1234)
Ubuntu (launchpad) https://bugs.launchpad.net/ (bln#1234)
Ximian http://bugzilla.ximian.com/ (Ximian #4321)

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


Номера ревизий 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 строк.
  • Расположите список изменений под информацией об обновлении версии.

Пример:

 - 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).


Назад

10. Специфичные пакеты

Вверх