Re: [devel] HOWTO по RPM-версионированию

[Kirill Maslinsky <kirill@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

On Thu, Dec 18, 2008 at 02:42:40PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 11:32:25 18.12.2008 UTC+03 when lav@altlinux.ru did gyre and gimble:
> 
>  >> Вопросы (и, что важнее, ошибки) по этой теме у начинающих
>  >> мантейнеров возникают очень часто, думаю, не в последнюю
>  >> очередь потому, что информация очень сильно разбросана по
>  >> разным источникам, зачастую архивам рассылки.
> 
>  VL> Может быть соберёмся с силами, выложим на вики?
> 
> Хорошо бы. Лучше не отдельно, а дописать в http://www.altlinux.org/Spec

[...]
On Thu, Dec 18, 2008 at 04:30:30PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 13:24:15 18.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:
> 
>  >> Сначала нужно зафиксировать правила, и только потом писать по ним HOWTO.
> 
>  KM> Согласен. Но что из обсуждаемых вопросов относится собственно к
>  KM> правилам? Насколько я понимаю, это в основном разъяснения принципов
>  KM> работы RPM
> 
> Принцип назначения версий, смысл Epoch, версионирование
> бэкпортов - это всё правила.
> 
> Twas brillig at 16:30:30 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:
[...]
> Точнее, справочный материал.

Я честно попытался дополнить по результатам обсуждения страницу Spec --
ну не выходит каменный цветок. Как ни крути, логика обсуждаемых задач
версионирования пакетов не укладывается в рамки справки по отдельным
полям спека. 

Как минимум, приходится вводить понятие "полная версия пакета", понимая
под этим "epoch:version-release", которые, собственно, и сравниваются 
между собой при обновлении пакетов. Задача мантейнера -- именно
обеспечивать правильный порядок этих полных версий при любом обновлении
(включая бранчи), сохраняя при этом разумный уровень детализации версии 
апстрима, позволяющий пользователю адекватно идентифицировать исходники.

Если писать это на странице Spec, то непонятно, в какое поле.
Создать раздел, объединяющий поля Version,Release,Epoch -- выпадает 
из логики справочника по полям спека, и вообще, по-хорошему, описывает
более общее понятие, относящееся к rpm-пакету в целом. 

В общем, надо, наверное, сделать отдельный справочник RPM-Versioning, 
если коллеги не согласны, что это HOWTO. А может быть правильнее
оформить это сразу как полиси? В этом случае раздел "правила нумерации
релизов" в http://www.altlinux.org/BackportsPolicy получается частным 
случаем такого общего полиси по нумерации версий.

С другой стороны, я по прежнему не уверен, что версионирование -- это
область, где нужно слишком жёстко регулировать. Важнее скорее разъяснить
основы, растолковать смысл версионирования и дать понятие о разных
стратегиях, так же, как с ведением git-репозитория.

PS Прошу прощения, что длинно, но мне этот момент представляется весьма
важным в работе по улучшению документации для разработчиков.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]