[devel-distro] branding

[Aleksey Novodvorsky]

чт, 5 авг. 2021 г., 20:57 Aleksey Novodvorsky <aen at basealt.ru>:

>
>
> чт, 5 авг. 2021 г., 20:41 Alexey Shabalin <a.shabalin at gmail.com>:
>
>> чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky <aen at basealt.ru>:
>> >
>> >
>> >
>> > чт, 5 авг. 2021 г., 19:38 Alexey Shabalin <a.shabalin at gmail.com>:
>> >>
>> >> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem at 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.
То есть версия -- это состояние бранча. На котором могут выпускаются
продукты.

Rgrds, Алексей

>
> И тогда:
>> - саппорт увидит что именно использует клиент;
>> - системы автоматизации и скрипты можно подготавливать и адаптировать
>> для дистрибутивов на p10;
>> - видно кто непавомерно обновился.
>>
>
> Мне, честно говоря, не нравятся разговоры о неправомерном  обновлении из
> свободного репозитория. Буду говорить с коммерческим блоком
>
> Rgrds, Алексей.
>
>>
>> Пусть пакет имеет версию 9.9 или 9.98, как любит sem@, но внутри в
>> /etc/os-release уже будет 10.0.
>> Обратная логика, предлагаемая sem at .
>>
>> --
>> Alexey Shabalin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.altlinux.org/pipermail/devel-distro/attachments/20210805/04d34504/attachment.html>