ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] rpm: deprecate GROUP
@ 2022-07-13 21:04 Andrey Savchenko
  2022-07-14  5:35 ` Anton Farygin
  2022-07-15 17:18 ` Dmitry V. Levin
  0 siblings, 2 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-13 21:04 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

Доброго времени суток!

Предлагаю перевести тег Group в разряд необязательных, устаревших
и рекомендовать его к удалению в новых или обновляемых пакетах.

Причины:
1) Перечень групп сильно устарел (например, там есть
и System/Xfree86, и System/X11).
2) Перечень сильно неполный и не соответсвует современным реалиям
(см. /usr/lib/rpm/GROUS).
3) Нередко тег выставляется спорный или к пакету применимы
несколько категорий.

По-моему, это лишь запутывает пользователей неполной, некорректной
и бесполезной информацией. Поэтому предлагаю постепенно от него
уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
вряд ли там что-то критичное.

На всякий посмотрел как в Федоре, там уже давно deprecated:
https://fedoraproject.org/wiki/RPMGroups

Что думаете?

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-13 21:04 [devel] rpm: deprecate GROUP Andrey Savchenko
@ 2022-07-14  5:35 ` Anton Farygin
  2022-07-14  7:24   ` Sergey V Turchin
  2022-07-15 17:18 ` Dmitry V. Levin
  1 sibling, 1 reply; 34+ messages in thread
From: Anton Farygin @ 2022-07-14  5:35 UTC (permalink / raw)
  To: devel

Да, идея напрашивается, но требуется переработка всего софта, в котором 
используются группы.
Из сложного там скорее всего synaptic.

Я бы начал с актуализации списка групп.


On 14.07.2022 00:04, Andrey Savchenko wrote:
> Доброго времени суток!
>
> Предлагаю перевести тег Group в разряд необязательных, устаревших
> и рекомендовать его к удалению в новых или обновляемых пакетах.
>
> Причины:
> 1) Перечень групп сильно устарел (например, там есть
> и System/Xfree86, и System/X11).
> 2) Перечень сильно неполный и не соответсвует современным реалиям
> (см. /usr/lib/rpm/GROUS).
> 3) Нередко тег выставляется спорный или к пакету применимы
> несколько категорий.
>
> По-моему, это лишь запутывает пользователей неполной, некорректной
> и бесполезной информацией. Поэтому предлагаю постепенно от него
> уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
> могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
> вряд ли там что-то критичное.
>
> На всякий посмотрел как в Федоре, там уже давно deprecated:
> https://fedoraproject.org/wiki/RPMGroups
>
> Что думаете?
>
> Best regards,
> Andrew Savchenko
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-14  5:35 ` Anton Farygin
@ 2022-07-14  7:24   ` Sergey V Turchin
  2022-07-14  8:16     ` Anton Farygin
  0 siblings, 1 reply; 34+ messages in thread
From: Sergey V Turchin @ 2022-07-14  7:24 UTC (permalink / raw)
  To: devel; +Cc: Anton Farygin

On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
> Да, идея напрашивается, но требуется переработка всего софта, в котором
> используются группы.
> Из сложного там скорее всего synaptic.
> 
> Я бы начал с актуализации списка групп.
Только если это не приведёт к тому, как сейчас с License, т.е. никогда не 
будет стремитсья стать обязательным.

Я бы:
1. Оставил поддержку групп.
2. Отключил все проверки на обязательность наличия тега.
3. При сборке переименовывал всякие System/X11 в System/Display, например.
4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ придумыал 
его себе сам. Например, "Misc".

[...]

-- 
Regards, Sergey.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-14  7:24   ` Sergey V Turchin
@ 2022-07-14  8:16     ` Anton Farygin
  2022-07-14  8:33       ` Sergey V Turchin
  0 siblings, 1 reply; 34+ messages in thread
From: Anton Farygin @ 2022-07-14  8:16 UTC (permalink / raw)
  To: devel

On 14.07.2022 10:24, Sergey V Turchin wrote:
> On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
>> Да, идея напрашивается, но требуется переработка всего софта, в котором
>> используются группы.
>> Из сложного там скорее всего synaptic.
>>
>> Я бы начал с актуализации списка групп.
> Только если это не приведёт к тому, как сейчас с License, т.е. никогда не
> будет стремитсья стать обязательным.
Группы уже обязательные (как и соответствие группам)
>
> Я бы:
> 1. Оставил поддержку групп.
> 2. Отключил все проверки на обязательность наличия тега.
Для начала проверить весь софт, как он переживёт осутствие группы.
> 3. При сборке переименовывал всякие System/X11 в System/Display, например.
> 4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ придумыал
> его себе сам. Например, "Misc".
>
> [...]
>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-14  8:16     ` Anton Farygin
@ 2022-07-14  8:33       ` Sergey V Turchin
  2022-07-16  3:11         ` P X
  0 siblings, 1 reply; 34+ messages in thread
From: Sergey V Turchin @ 2022-07-14  8:33 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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 ещё не обязателен, но когда-то будет, иначе он нафиг не 
нужон.

> > Я бы:
> > 1. Оставил поддержку групп.
> > 2. Отключил все проверки на обязательность наличия тега.
> Для начала проверить весь софт, как он переживёт осутствие группы.
Ну да. Сперва п.4 .
 
> > 3. При сборке переименовывал всякие System/X11 в System/Display, например.
> > 4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ
> > придумыал
> > его себе сам. Например, "Misc".
> > 
> > [...]
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 
Regards, Sergey.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-13 21:04 [devel] rpm: deprecate GROUP Andrey Savchenko
  2022-07-14  5:35 ` Anton Farygin
@ 2022-07-15 17:18 ` Dmitry V. Levin
  2022-07-16 10:08   ` Andrey Savchenko
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2022-07-15 17:18 UTC (permalink / raw)
  To: ALT Devel discussion list

On Thu, Jul 14, 2022 at 12:04:40AM +0300, Andrey Savchenko wrote:
> Доброго времени суток!
> 
> Предлагаю перевести тег Group в разряд необязательных, устаревших
> и рекомендовать его к удалению в новых или обновляемых пакетах.
> 
> Причины:
> 1) Перечень групп сильно устарел (например, там есть
> и System/Xfree86, и System/X11).
> 2) Перечень сильно неполный и не соответсвует современным реалиям
> (см. /usr/lib/rpm/GROUS).
> 3) Нередко тег выставляется спорный или к пакету применимы
> несколько категорий.
> 
> По-моему, это лишь запутывает пользователей неполной, некорректной
> и бесполезной информацией. Поэтому предлагаю постепенно от него
> уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
> могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
> вряд ли там что-то критичное.
> 
> На всякий посмотрел как в Федоре, там уже давно deprecated:
> https://fedoraproject.org/wiki/RPMGroups
> 
> Что думаете?

Я очень не люблю изменений ради изменений.

Не могу сказать, что тег Group мне дорог, но мне бы не хотелось, чтобы
1. сломались какие-то приложения вроде synaptic, наткнувшись на пакет без
  этого тэга;
2. кто-то потом пришёл с патчами по удалению тэга Group из спеков.

Если решить первый вопрос, то можно будет сперва сделать тег Group
необязательным, а потом и вовсе его игнорировать в спеке.


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-14  8:33       ` Sergey V Turchin
@ 2022-07-16  3:11         ` P X
  2022-07-16 10:05           ` Andrey Savchenko
  0 siblings, 1 reply; 34+ messages in thread
From: P X @ 2022-07-16  3:11 UTC (permalink / raw)
  To: devel

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 с подгруппами, как в 
остальных группах.

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

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-16  3:11         ` P X
@ 2022-07-16 10:05           ` Andrey Savchenko
  2022-07-16 10:53             ` [devel] License tag Dmitry V. Levin
  2022-07-16 16:30             ` [devel] rpm: deprecate GROUP Anton Farygin
  0 siblings, 2 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-16 10:05 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Sat, 16 Jul 2022 06:11:37 +0300 P X wrote:
> 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 ещё не обязателен, но когда-то будет, иначе он нафиг не
> > нужон.

SPDX опасен: one ring to rule them all. Удобный повод блокировать
неугодные лицензии. Не стоит его навязывать, особенно когда нет
всецелого доверия к управляющей организации, управляемой
корпорациями, а не сообществом. 

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

Однозначная классификация принципиально невозможна, текущая система
лишь запутывает пользователей и создаёт лишнии проблемы мейнтенерам.
Лучше тогда облако тегов добавить (массив ключевых слов), но под
это придётся переделывать софт.

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

Чем дисциплинирует? Создаёт лишнюю волокиту?

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-15 17:18 ` Dmitry V. Levin
@ 2022-07-16 10:08   ` Andrey Savchenko
  0 siblings, 0 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-16 10:08 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Fri, 15 Jul 2022 20:18:41 +0300 Dmitry V. Levin wrote:
> On Thu, Jul 14, 2022 at 12:04:40AM +0300, Andrey Savchenko wrote:
> > Доброго времени суток!
> > 
> > Предлагаю перевести тег Group в разряд необязательных, устаревших
> > и рекомендовать его к удалению в новых или обновляемых пакетах.
> > 
> > Причины:
> > 1) Перечень групп сильно устарел (например, там есть
> > и System/Xfree86, и System/X11).
> > 2) Перечень сильно неполный и не соответсвует современным реалиям
> > (см. /usr/lib/rpm/GROUS).
> > 3) Нередко тег выставляется спорный или к пакету применимы
> > несколько категорий.
> > 
> > По-моему, это лишь запутывает пользователей неполной, некорректной
> > и бесполезной информацией. Поэтому предлагаю постепенно от него
> > уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
> > могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
> > вряд ли там что-то критичное.
> > 
> > На всякий посмотрел как в Федоре, там уже давно deprecated:
> > https://fedoraproject.org/wiki/RPMGroups
> > 
> > Что думаете?
> 
> Я очень не люблю изменений ради изменений.
> 
> Не могу сказать, что тег Group мне дорог, но мне бы не хотелось, чтобы
> 1. сломались какие-то приложения вроде synaptic, наткнувшись на пакет без
>   этого тэга;
> 2. кто-то потом пришёл с патчами по удалению тэга Group из спеков.
> 
> Если решить первый вопрос, то можно будет сперва сделать тег Group
> необязательным, а потом и вовсе его игнорировать в спеке.

Я думаю, что достаточно в Synaptic вставить заглушку
Unclassified, если нет тега.

Удалять Group из спеков только ради этой операции действительно не
стоит, но при внесении иных изменений вполне можно совмещать.

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-16 10:05           ` Andrey Savchenko
@ 2022-07-16 10:53             ` Dmitry V. Levin
  2022-07-16 16:28               ` Anton Farygin
  2022-07-16 16:30             ` [devel] rpm: deprecate GROUP Anton Farygin
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2022-07-16 10:53 UTC (permalink / raw)
  To: devel

On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
[...]
> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> всецелого доверия к управляющей организации, управляемой
> корпорациями, а не сообществом. 

Мне кажется, что это проблема надуманная: спецификация SPDX
предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-16 10:53             ` [devel] License tag Dmitry V. Levin
@ 2022-07-16 16:28               ` Anton Farygin
  2022-07-16 17:25                 ` Alexey Gladkov
  0 siblings, 1 reply; 34+ messages in thread
From: Anton Farygin @ 2022-07-16 16:28 UTC (permalink / raw)
  To: devel

On 16.07.2022 13:53, Dmitry V. Levin wrote:
> On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
> [...]
>> SPDX опасен: one ring to rule them all. Удобный повод блокировать
>> неугодные лицензии. Не стоит его навязывать, особенно когда нет
>> всецелого доверия к управляющей организации, управляемой
>> корпорациями, а не сообществом.
> Мне кажется, что это проблема надуманная: спецификация SPDX
> предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.

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

SPDX скорее удобен чем неудобен, т.к. по сути является стандартом 
описания лицензии.

Например, благодаря ему мы сделали кликабельным лицензии и добавили в 
базу тексты:

https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] rpm: deprecate GROUP
  2022-07-16 10:05           ` Andrey Savchenko
  2022-07-16 10:53             ` [devel] License tag Dmitry V. Levin
@ 2022-07-16 16:30             ` Anton Farygin
  1 sibling, 0 replies; 34+ messages in thread
From: Anton Farygin @ 2022-07-16 16:30 UTC (permalink / raw)
  To: devel

On 16.07.2022 13:05, Andrey Savchenko wrote:
> On Sat, 16 Jul 2022 06:11:37 +0300 P X wrote:
>> 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.
>>>>>>
>>>>>> Я бы начал с актуализации списка групп.
> Смысл актуализировать то, что будет удаляться?
>
Для того, что бы понять, что группу можно не удалять, если начать ей 
пользоваться.

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-16 16:28               ` Anton Farygin
@ 2022-07-16 17:25                 ` Alexey Gladkov
  2022-07-17  8:09                   ` Andrey Savchenko
  2022-07-17 10:55                   ` Alexey V. Vissarionov
  0 siblings, 2 replies; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-16 17:25 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote:
> On 16.07.2022 13:53, Dmitry V. Levin wrote:
> > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
> > [...]
> >> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> >> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> >> всецелого доверия к управляющей организации, управляемой
> >> корпорациями, а не сообществом.
> > Мне кажется, что это проблема надуманная: спецификация SPDX
> > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.
> 
> SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. 
> есть и другие способы вычисления лицензий в проектах.
> 
> SPDX скорее удобен чем неудобен, т.к. по сути является стандартом 
> описания лицензии.
> 
> Например, благодаря ему мы сделали кликабельным лицензии и добавили в 
> базу тексты:
> 
> https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447

А можно посчитать сколько пакетов имеют не common-licenses совместимую
лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-16 17:25                 ` Alexey Gladkov
@ 2022-07-17  8:09                   ` Andrey Savchenko
  2022-07-17 11:19                     ` Dmitry V. Levin
  2022-07-17 12:15                     ` Alexey Gladkov
  2022-07-17 10:55                   ` Alexey V. Vissarionov
  1 sibling, 2 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-17  8:09 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote:
> > On 16.07.2022 13:53, Dmitry V. Levin wrote:
> > > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
> > > [...]
> > >> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> > >> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> > >> всецелого доверия к управляющей организации, управляемой
> > >> корпорациями, а не сообществом.
> > > Мне кажется, что это проблема надуманная: спецификация SPDX
> > > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.
> > 
> > SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. 
> > есть и другие способы вычисления лицензий в проектах.
> > 
> > SPDX скорее удобен чем неудобен, т.к. по сути является стандартом 
> > описания лицензии.
> > 
> > Например, благодаря ему мы сделали кликабельным лицензии и добавили в 
> > базу тексты:
> > 
> > https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447
> 
> А можно посчитать сколько пакетов имеют не common-licenses совместимую
> лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
 
А можно сперва обеспечить доступный каждому мейнтенеру механизм
добавления лицензий?

И да, в самом common-licenses полно ошибок, особенно в механизме
исключений. Да и лицензии большинства подпакетов указаны
некорректно, т.к. наследуют лицензии родительского пакета, а могут
содержать лишь какую-то часть под одной лицензией. Даже для
составляющих gcc они указаны некорректно. Более того, лицензии на
srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
в исходниках и только GPL в результирующем бинарнике), но у нас нет
даже механизма для обеспечения такого отличия. Но это борьба
с ветряными мельницами.

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-16 17:25                 ` Alexey Gladkov
  2022-07-17  8:09                   ` Andrey Savchenko
@ 2022-07-17 10:55                   ` Alexey V. Vissarionov
  2022-07-17 11:58                     ` Alexey Gladkov
  1 sibling, 1 reply; 34+ messages in thread
From: Alexey V. Vissarionov @ 2022-07-17 10:55 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-07-16 19:25:18 +0200, Alexey Gladkov wrote:

 >> SPDX скорее удобен чем неудобен, т.к. по сути является
 >> стандартом описания лицензии.
 > А можно посчитать сколько пакетов имеют не common-licenses
 > совместимую лицензию ? Может пора сделать в sisyphus_check
 > варнинг ошибкой ?

И тем самым перекрыть себе возможность собирать софт со
свободной, но своей собственной лицензией?

Не самое мудрое решение...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17  8:09                   ` Andrey Savchenko
@ 2022-07-17 11:19                     ` Dmitry V. Levin
  2022-07-17 14:31                       ` Andrey Savchenko
  2022-07-17 12:15                     ` Alexey Gladkov
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2022-07-17 11:19 UTC (permalink / raw)
  To: devel

On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
[...]
> > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
>  
> А можно сперва обеспечить доступный каждому мейнтенеру механизм
> добавления лицензий?
> 
> И да, в самом common-licenses полно ошибок, особенно в механизме
> исключений.

Например?


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 10:55                   ` Alexey V. Vissarionov
@ 2022-07-17 11:58                     ` Alexey Gladkov
  2022-07-17 21:07                       ` Alexey V. Vissarionov
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 11:58 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 01:55:54PM +0300, Alexey V. Vissarionov wrote:
> On 2022-07-16 19:25:18 +0200, Alexey Gladkov wrote:
> 
>  >> SPDX скорее удобен чем неудобен, т.к. по сути является
>  >> стандартом описания лицензии.
>  > А можно посчитать сколько пакетов имеют не common-licenses
>  > совместимую лицензию ? Может пора сделать в sisyphus_check
>  > варнинг ошибкой ?
> 
> И тем самым перекрыть себе возможность собирать софт со
> свободной, но своей собственной лицензией?
> 
> Не самое мудрое решение...

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

Как и раньше у нас есть механизм для добавления лицензий в
common-licenses. Мантейнер пакета с такой уникальной лицензией может
обратиться в багзиллу и добавить лицензию.

В общем-то я не вижу какой-то уникальности в этом случае.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17  8:09                   ` Andrey Savchenko
  2022-07-17 11:19                     ` Dmitry V. Levin
@ 2022-07-17 12:15                     ` Alexey Gladkov
  2022-07-17 13:03                       ` Dmitry V. Levin
  2022-07-18  7:03                       ` Andrey Savchenko
  1 sibling, 2 replies; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 12:15 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> > On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote:
> > > On 16.07.2022 13:53, Dmitry V. Levin wrote:
> > > > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
> > > > [...]
> > > >> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> > > >> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> > > >> всецелого доверия к управляющей организации, управляемой
> > > >> корпорациями, а не сообществом.
> > > > Мне кажется, что это проблема надуманная: спецификация SPDX
> > > > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.
> > > 
> > > SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. 
> > > есть и другие способы вычисления лицензий в проектах.
> > > 
> > > SPDX скорее удобен чем неудобен, т.к. по сути является стандартом 
> > > описания лицензии.
> > > 
> > > Например, благодаря ему мы сделали кликабельным лицензии и добавили в 
> > > базу тексты:
> > > 
> > > https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447
> > 
> > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
>  
> А можно сперва обеспечить доступный каждому мейнтенеру механизм
> добавления лицензий?

Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже
использовался не раз.

> И да, в самом common-licenses полно ошибок, особенно в механизме
> исключений. Да и лицензии большинства подпакетов указаны
> некорректно, т.к. наследуют лицензии родительского пакета, а могут
> содержать лишь какую-то часть под одной лицензией. Даже для
> составляющих gcc они указаны некорректно. Более того, лицензии на
> srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> в исходниках и только GPL в результирующем бинарнике), но у нас нет
> даже механизма для обеспечения такого отличия.

Тэг License может быть указан в подпакетах. Это позволяет указать разные
лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
Либо я не понял вас.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 12:15                     ` Alexey Gladkov
@ 2022-07-17 13:03                       ` Dmitry V. Levin
  2022-07-17 13:11                         ` Alexey Gladkov
  2022-07-18  7:03                       ` Andrey Savchenko
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2022-07-17 13:03 UTC (permalink / raw)
  To: devel

On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
[...]
> > Более того, лицензии на
> > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > даже механизма для обеспечения такого отличия.
> 
> Тэг License может быть указан в подпакетах. Это позволяет указать разные
> лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> Либо я не понял вас.

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


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:03                       ` Dmitry V. Levin
@ 2022-07-17 13:11                         ` Alexey Gladkov
  2022-07-17 13:25                           ` Dmitry V. Levin
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 13:11 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> [...]
> > > Более того, лицензии на
> > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > даже механизма для обеспечения такого отличия.
> > 
> > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > Либо я не понял вас.
> 
> Наверное, речь идёт о том, что нет возможности указать разные лицензии
> для исходного пакета и для собранного из него одноимённого бинарного.

Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
либо исходный, либо бинарный пакет.

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

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:11                         ` Alexey Gladkov
@ 2022-07-17 13:25                           ` Dmitry V. Levin
  2022-07-17 13:38                             ` Alexey Gladkov
  0 siblings, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2022-07-17 13:25 UTC (permalink / raw)
  To: devel

On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote:
> On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > [...]
> > > > Более того, лицензии на
> > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > > даже механизма для обеспечения такого отличия.
> > > 
> > > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > > Либо я не понял вас.
> > 
> > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > для исходного пакета и для собранного из него одноимённого бинарного.
> 
> Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> либо исходный, либо бинарный пакет.

Часто бывает, что из исходного пакета собирается несколько бинарных,
в том числе один одноимённый, причём лицензии бинарных пакетов являются
подмножеством исходного, например, из исходного пакета собирается library
под лицензией LGPL-3.0-or-later и executable под лицензией
GPL-3.0-or-later.  В такой ситуации бывает, что и переименовывать
не во что.


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:25                           ` Dmitry V. Levin
@ 2022-07-17 13:38                             ` Alexey Gladkov
  2022-07-17 13:40                               ` Alexey Gladkov
  2022-07-17 14:39                               ` Andrey Savchenko
  0 siblings, 2 replies; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 13:38 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 04:25:01PM +0300, Dmitry V. Levin wrote:
> On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> > > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > > [...]
> > > > > Более того, лицензии на
> > > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > > > даже механизма для обеспечения такого отличия.
> > > > 
> > > > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > > > Либо я не понял вас.
> > > 
> > > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > > для исходного пакета и для собранного из него одноимённого бинарного.
> > 
> > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> > либо исходный, либо бинарный пакет.
> 
> Часто бывает, что из исходного пакета собирается несколько бинарных,
> в том числе один одноимённый, причём лицензии бинарных пакетов являются
> подмножеством исходного, например, из исходного пакета собирается library
> под лицензией LGPL-3.0-or-later и executable под лицензией
> GPL-3.0-or-later.  В такой ситуации бывает, что и переименовывать
> не во что.

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

Может быть ввести тэг License-src какой-нибудь ?

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:38                             ` Alexey Gladkov
@ 2022-07-17 13:40                               ` Alexey Gladkov
  2022-07-17 20:46                                 ` Alexey V. Vissarionov
  2022-07-17 14:39                               ` Andrey Savchenko
  1 sibling, 1 reply; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 13:40 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 03:38:37PM +0200, Alexey Gladkov wrote:
> > > > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > > > для исходного пакета и для собранного из него одноимённого бинарного.
> > > 
> > > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> > > либо исходный, либо бинарный пакет.
> > 
> > Часто бывает, что из исходного пакета собирается несколько бинарных,
> > в том числе один одноимённый, причём лицензии бинарных пакетов являются
> > подмножеством исходного, например, из исходного пакета собирается library
> > под лицензией LGPL-3.0-or-later и executable под лицензией
> > GPL-3.0-or-later.  В такой ситуации бывает, что и переименовывать
> > не во что.
> 
> Придумать можно, но повторюсь, что я согласен, что не очень удобно это.
> 
> Может быть ввести тэг License-src какой-нибудь ?

Ну или забить вообще на эти лицензии. Потому что складывается ощущение,
что это всё нафиг никому не нужно.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 11:19                     ` Dmitry V. Levin
@ 2022-07-17 14:31                       ` Andrey Savchenko
  0 siblings, 0 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-17 14:31 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Sun, 17 Jul 2022 14:19:19 +0300 Dmitry V. Levin wrote:
> On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> [...]
> > > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
> >  
> > А можно сперва обеспечить доступный каждому мейнтенеру механизм
> > добавления лицензий?
> > 
> > И да, в самом common-licenses полно ошибок, особенно в механизме
> > исключений.
> 
> Например?

У gcc больше исключений, чем есть в common-licenses. Я когда-то на
это напоролся и оставил в стороне, т.к. лицензии на подпакеты,
в частности библиотеки некорретны (избыточны). С openssl тоже: там
куда больше исключений, чем openvpn и все они типовые.

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:38                             ` Alexey Gladkov
  2022-07-17 13:40                               ` Alexey Gladkov
@ 2022-07-17 14:39                               ` Andrey Savchenko
  2022-07-17 20:55                                 ` Alexey V. Vissarionov
  1 sibling, 1 reply; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-17 14:39 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Sun, 17 Jul 2022 15:38:37 +0200 Alexey Gladkov wrote:
> On Sun, Jul 17, 2022 at 04:25:01PM +0300, Dmitry V. Levin wrote:
> > On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote:
> > > On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> > > > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > > > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > > > [...]
> > > > > > Более того, лицензии на
> > > > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > > > > даже механизма для обеспечения такого отличия.
> > > > > 
> > > > > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > > > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > > > > Либо я не понял вас.
> > > > 
> > > > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > > > для исходного пакета и для собранного из него одноимённого бинарного.
> > > 
> > > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> > > либо исходный, либо бинарный пакет.
> > 
> > Часто бывает, что из исходного пакета собирается несколько бинарных,
> > в том числе один одноимённый, причём лицензии бинарных пакетов являются
> > подмножеством исходного, например, из исходного пакета собирается library
> > под лицензией LGPL-3.0-or-later и executable под лицензией
> > GPL-3.0-or-later.  В такой ситуации бывает, что и переименовывать
> > не во что.
> 
> Придумать можно, но повторюсь, что я согласен, что не очень удобно это.
> 
> Может быть ввести тэг License-src какой-нибудь ?

Это хорошая идея, но можно пойти дальше и упростить мейнтенерам
жизнь. Лицензия на src.rpm будет включать в себя все лицензии
подпакетов, но может и иметь дополнительные (например, софт GPL,
а инструменты для сборки (configure, am) BSD). Думаю, что ситуация,
когда в бинарном пакете или подпакете есть лицензия, которая не
попадает распространяется на пакет с исходном нереалистична.

Поэтому можно автоформировать License у srpm как объединение
множеств всех лицензий (под)пакетов и добавить тег вида
License-src-extra для указания дополнительных лицензий, которые есть
только в исходниках, но не попадают в бинарные пакеты.

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 13:40                               ` Alexey Gladkov
@ 2022-07-17 20:46                                 ` Alexey V. Vissarionov
  2022-07-17 22:35                                   ` Alexey Gladkov
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey V. Vissarionov @ 2022-07-17 20:46 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-07-17 15:40:55 +0200, Alexey Gladkov wrote:

 >>> Часто бывает, что из исходного пакета собирается несколько
 >>> бинарных, в том числе один одноимённый, причём лицензии
 >>> бинарных пакетов являются подмножеством исходного, например,
 >>> из исходного пакета собирается library под лицензией
 >>> LGPL-3.0-or-later и executable под лицензией
 >>> GPL-3.0-or-later. В такой ситуации бывает, что и
 >>> переименовывать не во что.
 >> Придумать можно, но повторюсь, что я согласен, что не очень
 >> удобно это.
 >> Может быть ввести тэг License-src какой-нибудь ?
 > Ну или забить вообще на эти лицензии. Потому что складывается
 > ощущение, что это всё нафиг никому не нужно.

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

Так что вполне можно оставить решение этого вопроса на усмотрение
мейнтейнеров. А нынешние предупреждения... да в общем-то пусть
будут: вреда от них никакого, а польза бывает.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 14:39                               ` Andrey Savchenko
@ 2022-07-17 20:55                                 ` Alexey V. Vissarionov
  2022-07-18  6:31                                   ` Andrey Savchenko
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey V. Vissarionov @ 2022-07-17 20:55 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-07-17 17:39:47 +0300, Andrey Savchenko wrote:

 >> Придумать можно, но повторюсь, что я согласен, что не очень
 >> удобно это.
 >> Может быть ввести тэг License-src какой-нибудь ?
 > Это хорошая идея,

Я все больше склоняюсь к мысли, что это был сарказм.

 > но можно пойти дальше и упростить мейнтенерам жизнь.

Прочитал, общую идею уловил. Сколько часов в месяц это сэкономит
типовому мейнтейнеру? И каким образом?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 11:58                     ` Alexey Gladkov
@ 2022-07-17 21:07                       ` Alexey V. Vissarionov
  0 siblings, 0 replies; 34+ messages in thread
From: Alexey V. Vissarionov @ 2022-07-17 21:07 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-07-17 13:58:32 +0200, Alexey Gladkov wrote:

 >>>> SPDX скорее удобен чем неудобен, т.к. по сути является
 >>>> стандартом описания лицензии.
 >>> А можно посчитать сколько пакетов имеют не common-licenses
 >>> совместимую лицензию ? Может пора сделать в sisyphus_check
 >>> варнинг ошибкой ?
 >> И тем самым перекрыть себе возможность собирать софт со
 >> свободной, но своей собственной лицензией?
 >> Не самое мудрое решение...
 > Не самое мудрое решение изобретать свою лицензию, но если
 > есть настолько амбициозный разработчик, то его лицензию
 > просто необходимо проверить на соответствие свободности.

Случаи бывают всякие. Помнится, году этак в 2004...2005 мне
нужно было передать своему тогдашнему работодателю кое-какой
код, и если бы я не нашел (ныне мою любимую) WTFPL, которая
появилась буквально за полгода до описываемых событий, я бы
ее просто придумал сам.

И да: лицензия - свободнее не бывает.

 > Как и раньше у нас есть механизм для добавления лицензий
 > в common-licenses. Мантейнер пакета с такой уникальной
 > лицензией может обратиться в багзиллу и добавить лицензию.
 > В общем-то я не вижу какой-то уникальности в этом случае.

Трата времени. Пусть однократная, но все же.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 20:46                                 ` Alexey V. Vissarionov
@ 2022-07-17 22:35                                   ` Alexey Gladkov
  2022-07-18  8:18                                     ` Alexey V. Vissarionov
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-17 22:35 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sun, Jul 17, 2022 at 11:46:15PM +0300, Alexey V. Vissarionov wrote:
> On 2022-07-17 15:40:55 +0200, Alexey Gladkov wrote:
> 
>  >>> Часто бывает, что из исходного пакета собирается несколько
>  >>> бинарных, в том числе один одноимённый, причём лицензии
>  >>> бинарных пакетов являются подмножеством исходного, например,
>  >>> из исходного пакета собирается library под лицензией
>  >>> LGPL-3.0-or-later и executable под лицензией
>  >>> GPL-3.0-or-later. В такой ситуации бывает, что и
>  >>> переименовывать не во что.
>  >> Придумать можно, но повторюсь, что я согласен, что не очень
>  >> удобно это.
>  >> Может быть ввести тэг License-src какой-нибудь ?
>  > Ну или забить вообще на эти лицензии. Потому что складывается
>  > ощущение, что это всё нафиг никому не нужно.
> 
> По большому счету - да: лично я не знаю ни одного случая, чтобы
> типовой пользователь отказался от установки софта из-за того,
> что ему не нравится определенная свободная лицензия. Нетиповые
> могут, но их пренебрежимо мало.

Вы вероятно не знаете, но в common-licenses у нас не только свободные
лицензии, а в репозиториях не только свободные пакеты.

Некоторые пакеты можно использовать только на определённых условиях.

> Так что вполне можно оставить решение этого вопроса на усмотрение
> мейнтейнеров. А нынешние предупреждения... да в общем-то пусть
> будут: вреда от них никакого, а польза бывает.
> 
> 
> -- 
> Alexey V. Vissarionov
> gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
> GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 20:55                                 ` Alexey V. Vissarionov
@ 2022-07-18  6:31                                   ` Andrey Savchenko
  0 siblings, 0 replies; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-18  6:31 UTC (permalink / raw)
  To: ALT Linux Team development discussions; +Cc: Alexey V. Vissarionov

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

On Sun, 17 Jul 2022 23:55:02 +0300 Alexey V. Vissarionov wrote:
> On 2022-07-17 17:39:47 +0300, Andrey Savchenko wrote:
> 
>  > но можно пойти дальше и упростить мейнтенерам жизнь.
> 
> Прочитал, общую идею уловил. Сколько часов в месяц это сэкономит
> типовому мейнтейнеру?

Зависит от активности мейнтенера: сколько событий при которых
необходим анализ лицензии происходит. Это как минимум добавления
новых пакетов или серьёзные изменения имеющихся. Трудозатраты на
одно такое событие зависят от размера и качества пакета, но в целом
в нулевом порядке приближения я бы оценил экономию в 20 минут на
событие. Если проверка на наличие лицензии в common-licenses будет
обязательной, то такие события наступят разово для всех пакетов.

> И каким образом?

Экономия достигается за счёт того, что не нужно вручную указывать
лицензию для srpm в типовых случаях, а в нетиповых работы будет
меньше.

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 12:15                     ` Alexey Gladkov
  2022-07-17 13:03                       ` Dmitry V. Levin
@ 2022-07-18  7:03                       ` Andrey Savchenko
  2022-07-18 11:04                         ` Alexey Gladkov
  1 sibling, 1 reply; 34+ messages in thread
From: Andrey Savchenko @ 2022-07-18  7:03 UTC (permalink / raw)
  To: ALT Linux Team development discussions

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

On Sun, 17 Jul 2022 14:15:06 +0200 Alexey Gladkov wrote:
> On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> > > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
> >  
> > А можно сперва обеспечить доступный каждому мейнтенеру механизм
> > добавления лицензий?
> 
> Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже
> использовался не раз.

Если это штатный механизм, то нужно SLA по нему, чтоб люди не ждали
годами[1] добавления лицензии.

[1] https://bugzilla.altlinux.org/38953

Я думаю, что неделя - разумный срок, т.к. невозможность добавления
лицензии блокирует работы по пакету (это может быть как добавление
пакета, так и обновление, при котором сменилась лицензия или просто
исправление ранее не вполне корректно указанной информации о
лицензии).

Best regards,
Andrew Savchenko

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-17 22:35                                   ` Alexey Gladkov
@ 2022-07-18  8:18                                     ` Alexey V. Vissarionov
  2022-07-18 11:12                                       ` Alexey Gladkov
  0 siblings, 1 reply; 34+ messages in thread
From: Alexey V. Vissarionov @ 2022-07-18  8:18 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-07-18 00:35:11 +0200, Alexey Gladkov wrote:

 >>>> Может быть ввести тэг License-src какой-нибудь ?
 >>> Ну или забить вообще на эти лицензии. Потому что складывается
 >>> ощущение, что это всё нафиг никому не нужно.
 >> По большому счету - да: лично я не знаю ни одного случая, чтобы
 >> типовой пользователь отказался от установки софта из-за того,
 >> что ему не нравится определенная свободная лицензия. Нетиповые
 >> могут, но их пренебрежимо мало.
 > Вы вероятно не знаете, но в common-licenses у нас не только
 > свободные лицензии, а в репозиториях не только свободные пакеты.

Ну ладно: s/свободная/distributable/
Что-то принципиально меняется? На мой взгляд - ничего, причем в
точности по той же причине: идейных пренебрежимо мало.

 > Некоторые пакеты можно использовать только на определённых
 > условиях.

Много вы знаете пользователей, которые внимательно изучают эти
условия? Большинству из них вообще нет дела до каких-то там
лицензий, а почти всем остальным хватает "distributable - ну и
хорошо".

 >> Так что вполне можно оставить решение этого вопроса на
 >> усмотрение мейнтейнеров. А нынешние предупреждения...
 >> да в общем-то пусть будут: вреда от них никакого, а польза
 >> бывает.

Здесь, насколько я понимаю, возражений нет?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-18  7:03                       ` Andrey Savchenko
@ 2022-07-18 11:04                         ` Alexey Gladkov
  0 siblings, 0 replies; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-18 11:04 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Mon, Jul 18, 2022 at 10:03:19AM +0300, Andrey Savchenko wrote:
> On Sun, 17 Jul 2022 14:15:06 +0200 Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> > > > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
> > >  
> > > А можно сперва обеспечить доступный каждому мейнтенеру механизм
> > > добавления лицензий?
> > 
> > Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже
> > использовался не раз.
> 
> Если это штатный механизм, то нужно SLA по нему, чтоб люди не ждали
> годами[1] добавления лицензии.
> 
> [1] https://bugzilla.altlinux.org/38953
> 
> Я думаю, что неделя - разумный срок, т.к. невозможность добавления
> лицензии блокирует работы по пакету (это может быть как добавление
> пакета, так и обновление, при котором сменилась лицензия или просто
> исправление ранее не вполне корректно указанной информации о
> лицензии).

Судя по истории изменений я просто не заметил этой баги. Да, если за
неделю не произошло реакции я думаю можно поднимать приоритет и пинать.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] License tag
  2022-07-18  8:18                                     ` Alexey V. Vissarionov
@ 2022-07-18 11:12                                       ` Alexey Gladkov
  0 siblings, 0 replies; 34+ messages in thread
From: Alexey Gladkov @ 2022-07-18 11:12 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Mon, Jul 18, 2022 at 11:18:06AM +0300, Alexey V. Vissarionov wrote:
> On 2022-07-18 00:35:11 +0200, Alexey Gladkov wrote:
> 
>  >>>> Может быть ввести тэг License-src какой-нибудь ?
>  >>> Ну или забить вообще на эти лицензии. Потому что складывается
>  >>> ощущение, что это всё нафиг никому не нужно.
>  >> По большому счету - да: лично я не знаю ни одного случая, чтобы
>  >> типовой пользователь отказался от установки софта из-за того,
>  >> что ему не нравится определенная свободная лицензия. Нетиповые
>  >> могут, но их пренебрежимо мало.
>  > Вы вероятно не знаете, но в common-licenses у нас не только
>  > свободные лицензии, а в репозиториях не только свободные пакеты.
> 
> Ну ладно: s/свободная/distributable/
> Что-то принципиально меняется? На мой взгляд - ничего, причем в
> точности по той же причине: идейных пренебрежимо мало.
> 
>  > Некоторые пакеты можно использовать только на определённых
>  > условиях.
> 
> Много вы знаете пользователей, которые внимательно изучают эти
> условия? Большинству из них вообще нет дела до каких-то там
> лицензий, а почти всем остальным хватает "distributable - ну и
> хорошо".
> 
>  >> Так что вполне можно оставить решение этого вопроса на
>  >> усмотрение мейнтейнеров. А нынешние предупреждения...
>  >> да в общем-то пусть будут: вреда от них никакого, а польза
>  >> бывает.
> 
> Здесь, насколько я понимаю, возражений нет?

Есть, но я просто хочу свернуть эту дискуссию. Мне не хочется поддерживать
пустой спор. Раз вы не видите в этом толка - ок. Я не планирую вас
убеждать.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2022-07-18 11:12 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-13 21:04 [devel] rpm: deprecate GROUP Andrey Savchenko
2022-07-14  5:35 ` Anton Farygin
2022-07-14  7:24   ` Sergey V Turchin
2022-07-14  8:16     ` Anton Farygin
2022-07-14  8:33       ` Sergey V Turchin
2022-07-16  3:11         ` P X
2022-07-16 10:05           ` Andrey Savchenko
2022-07-16 10:53             ` [devel] License tag Dmitry V. Levin
2022-07-16 16:28               ` Anton Farygin
2022-07-16 17:25                 ` Alexey Gladkov
2022-07-17  8:09                   ` Andrey Savchenko
2022-07-17 11:19                     ` Dmitry V. Levin
2022-07-17 14:31                       ` Andrey Savchenko
2022-07-17 12:15                     ` Alexey Gladkov
2022-07-17 13:03                       ` Dmitry V. Levin
2022-07-17 13:11                         ` Alexey Gladkov
2022-07-17 13:25                           ` Dmitry V. Levin
2022-07-17 13:38                             ` Alexey Gladkov
2022-07-17 13:40                               ` Alexey Gladkov
2022-07-17 20:46                                 ` Alexey V. Vissarionov
2022-07-17 22:35                                   ` Alexey Gladkov
2022-07-18  8:18                                     ` Alexey V. Vissarionov
2022-07-18 11:12                                       ` Alexey Gladkov
2022-07-17 14:39                               ` Andrey Savchenko
2022-07-17 20:55                                 ` Alexey V. Vissarionov
2022-07-18  6:31                                   ` Andrey Savchenko
2022-07-18  7:03                       ` Andrey Savchenko
2022-07-18 11:04                         ` Alexey Gladkov
2022-07-17 10:55                   ` Alexey V. Vissarionov
2022-07-17 11:58                     ` Alexey Gladkov
2022-07-17 21:07                       ` Alexey V. Vissarionov
2022-07-16 16:30             ` [devel] rpm: deprecate GROUP Anton Farygin
2022-07-15 17:18 ` Dmitry V. Levin
2022-07-16 10:08   ` Andrey Savchenko

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git