[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