[devel] rpm: deprecate GROUP

P X ruslandh на gmail.com
Сб Июл 16 06:11:37 MSK 2022


14.07.2022 11:33, Sergey V Turchin пишет:
> On Thursday, 14 July 2022 11:16:12 MSK Anton Farygin wrote:
>> On 14.07.2022 10:24, Sergey V Turchin wrote:
>>> On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
>>>> Да, идея напрашивается, но требуется переработка всего софта, в котором
>>>> используются группы.
>>>> Из сложного там скорее всего synaptic.
>>>>
>>>> Я бы начал с актуализации списка групп.
>>>
>>> Только если это не приведёт к тому, как сейчас с License, т.е. никогда не
>>> будет стремитсья стать обязательным.
>> Группы уже обязательные (как и соответствие группам)
> Ещё. И не только необязательны, но и запрещены. Речь про пока несуществующие
> группы, которые возникнут после актуализации.
> А SPDX в License ещё не обязателен, но когда-то будет, иначе он нафиг не
> нужон.


  Не вижу особого смысла в удалении групп. Как я понимаю, смысл групп 
всегда был в поиске пользователя подходящего пакета и изучении из каких 
пакетов состоит система и для чего тот или иной пакетв приложениях типа 
aptitude synaptic и т.п. Этот смыл как был, так и остался. Я бы только 
актуализировал название групп, если их название сильно устарело.

  В новых названиих групп, я-бы ориентировался на стандарт меню 
приложений, что-бы название группы  коррелировало с группами меню.
Даже если пакет не имеет десктоп файлов, всё равно можно ориентироваться 
на этот стандарт, как-бы его расширяя, ведь любая библиотека служит для 
определённых приложений.
А вот для консольных приложений можно подумать о том, в какую-бы группу 
оно вошло, будь у неё десктоп файл.
Или возможно какая-то большая группа типа no-menu с подгруппами, как в 
остальных группах.

  При таком принципе пользователю легче понимать где в меню может 
оказаться то или иное приложение, или для каких приложений нужна та, или 
иная библиотека.

И я бы оставил обязательность групп, это дисциплинирует мантейнера.




Подробная информация о списке рассылки Devel