Re: [devel-distro] branding

[Alexey Shabalin <a.shabalin@gmail.com>]

чт, 5 авг. 2021 г. в 21:12, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
> чт, 5 авг. 2021 г., 20:57 Aleksey Novodvorsky <aen@basealt.ru>:
>>
>>
>>
>> чт, 5 авг. 2021 г., 20:41 Alexey Shabalin <a.shabalin@gmail.com>:
>>>
>>> чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky <aen@basealt.ru>:
>>> >
>>> >
>>> >
>>> > чт, 5 авг. 2021 г., 19:38 Alexey Shabalin <a.shabalin@gmail.com>:
>>> >>
>>> >> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem@altlinux.org>:
>>> >> >
>>> >> > On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>>> >> > > По сути же, мне не нравится любое изменение , не согласованное со всеми
>>> >> > > релиз-менеджерами.
>>> >> >
>>> >> > Когда я о нем писал почти никто не отреагировал:
>>> >> > https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>>> >>
>>> >> Для релиз менеджера, который тестирует разные beta и rc, причем
>>> >> исключительно новыми установками, это изменение возможно полезное.
>>> >> Но на системах, которые никакого отношения не имеют к beta, установка
>>> >> только из релиза и в дальнейшем многолетняя эксплуатация с
>>> >> обновлениями, это изменение вредное.
>>> >>
>>> >> Давай попробуем не рассматривать юридические аспекты, остановимся
>>> >> только на технических.
>>> >> При эксплуатации и  обслуживании системы, через пару-тройку лет, а еще
>>> >> и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно все равно,
>>> >> откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо важнее, текущее
>>> >> состояние версии - 8, 9 или 10. И для этого есть стандартное место -
>>> >> /etc/os-release или /etc/altlinux-release.
>>> >> Заглянуть в эти файлы проще, чем делать rpm -q --qf "%{VERSION}"
>>> >> branding-alt-workstation-release, а еще перед этим надо узнать имя
>>> >> пакета, workstation или какое-другое.
>>> >> А дальше еще нужно переписать кучу софта, который смотрит в /etc/os-release.
>>> >> Вы готовы пропатчить все возможное? Начиная с python3-module-distro,
>>> >> platform.freedesktop_os_release() в будущем python-3.10? Кучу
>>> >> остального прикладного софта?
>>> >> Этот прикладной софт не знает, что было придумано в Альт в 2017 году.
>>> >> Во всех дистрибутивах принято в /etc/os-release хранить текущую версию
>>> >> (ок, называйте как угодно, пусть будет версия пакета branding, а не
>>> >> версия дистрибутива - меня устроит любое определение). У альт и так
>>> >> много специфических отличий, но зачем тут создавать ненужное отличие
>>> >> на ровном месте?
>>> >
>>> >
>>> > На ровном месте точно не нужно.
>>> > Давайте обратимся к "мелочам".
>>> > Что должно быть в os-release у обновившихся с p9 до p10 до выхода 10.0?
>>>
>>> Лучше, чтобы уже было написано "10.0". Вас это все равно ни к чему не
>>> обязывает - релиза еще не было и iso образов еще нет.
>>
>>
>> У нас именно в 10.0 будут новшества в apt, работа идёт, мы говорили об этом. А бранч будет доступен для обновления раньше.
>> То есть это как раз пример того, когда номер релиза, пусть условный, не дает нужной информации.
>
>
> Возможно, стоит считать начальный бранч релизом 0 ,   а продукты выпускать начиная с 1.
> То есть версия -- это состояние бранча. На котором могут выпускаются продукты.

Не стоит переусложнять. Ничто не мешает выпустить продукты с "10.0".

-- 
Alexey Shabalin