[devel] Q: PEP-503/566 normalized names for python?

[devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

Уважаемые господа,

Обсуждал с rider@ недостаточный охват python* пакетов сервисом watch,
вспомнил, что там не хватает сервиса pypi watch, 
а написать его мешает тот факт, что у нас 
до сих пор не реализованы канонические имена 
для исходных питоньих модулей.
Так называемые "normalized names"
сначала https://www.python.org/dev/peps/pep-0503/
потом https://www.python.org/dev/peps/pep-0566/

В rpm-based дистрибутивах (SuSE,Mandriva,Fedora) уже сложился
стандарт их применения:
1) в бинарных файлах есть pythonNNdist(normalizedname) Provides.
Пример из OpenSuSE:
$ rpmquery --provides -p python3-ZEO-5.2.1-3.5.noarch.rpm | grep dist
python3.8dist(zeo) = 5.2.1
python3dist(zeo) = 5.2.1

И что хорошо, normalized names в пакет руками добавлять не нужно.
Эти имена используются в egg-info, их легко получить оттуда.
если добавить в rpm-build-pythonN pythonNdist.prov,
который будет генерировать Provides: python3dist(normalizedname).
При чем готовый код для prov можно подсмотреть из той же Fedora.

2) рекомендовать называть пакет
pythonN-module-normalizedname.
А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
может быть упакетван как
python3-module-foo
python3-module-pyfoo
python3-module-Foo
python3-module-PyFoo

еще больще вариатов для, к примеру,
Py_Foo (normalized name py-foo)

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Igor Vlasenko писал 22.9.20 20:06:
> Уважаемые господа,
> 
> Обсуждал с rider@ недостаточный охват python* пакетов сервисом watch,
> вспомнил, что там не хватает сервиса pypi watch,
> а написать его мешает тот факт, что у нас
> до сих пор не реализованы канонические имена
> для исходных питоньих модулей.
> Так называемые "normalized names"
> сначала https://www.python.org/dev/peps/pep-0503/
> потом https://www.python.org/dev/peps/pep-0566/

Я очень за канонические имена, как раз хотел писать письмо о том, что у 
нас пакеты называются вразнобой,
и отчасти путаница эта вызвана тем, что существуют пакеты python, модули 
python, и ещё и rpm-пакеты python.

...> И что хорошо, normalized names в пакет руками добавлять не нужно.
> Эти имена используются в egg-info, их легко получить оттуда.
> если добавить в rpm-build-pythonN pythonNdist.prov,
> который будет генерировать Provides: python3dist(normalizedname).
> При чем готовый код для prov можно подсмотреть из той же Fedora.
> 
> 2) рекомендовать называть пакет
> pythonN-module-normalizedname.
Не то что руками добавлять, а ещё и пакет переименовать :)

> А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
> может быть упакетван как
> python3-module-foo
> python3-module-pyfoo
> python3-module-Foo
> python3-module-PyFoo
Это обычно связано с названием пакета на pypi.org.

Я предлагаю ещё добавить рекомендацию в зависимостях указывать не 
названия rpm-пакетов и не названия модулей python, а эти самые 
pythonNdist(normalizedname).

Ну и рекомендации эти вписать в Policy.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Tue, Sep 22, 2020 at 08:06:01PM +0300, Igor Vlasenko wrote:
> И что хорошо, normalized names в пакет руками добавлять не нужно.
> Эти имена используются в egg-info, их легко получить оттуда.
> если добавить в rpm-build-pythonN pythonNdist.prov,
> который будет генерировать Provides: python3dist(normalizedname).
> При чем готовый код для prov можно подсмотреть из той же Fedora.

/usr/lib/rpm/pythondistdeps.py
в пакете fedora/linux/development/rawhide/Everything/x86_64/os/Packages/p/python3-rpm-generators-11-11.fc33.noarch.rpm


-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Tue, Sep 22, 2020 at 08:27:34PM +0300, Vitaly Lipatov wrote:
> Я предлагаю ещё добавить рекомендацию в зависимостях указывать не названия
> rpm-пакетов и не названия модулей python, а эти самые
> pythonNdist(normalizedname).
> 
> Ну и рекомендации эти вписать в Policy.

плюсую.

Еще хотел бы подчеркнуть, что стоило бы не изобретать велосипед,
а взять готовый код 
# RPM python dependency generator, using .egg-info/.egg-link/.dist-info data
pythondistdeps.py --provides --normalized-names-format pep503

чтобы из-за случайного дефекта реализации не сломалась бы
совместимость по Provides: с остальными дистрибутивами.

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Igor Vlasenko писал 22.9.20 20:48:
...
> Еще хотел бы подчеркнуть, что стоило бы не изобретать велосипед,
> а взять готовый код
> # RPM python dependency generator, using .egg-info/.egg-link/.dist-info 
> data
> pythondistdeps.py --provides --normalized-names-format pep503
> 
> чтобы из-за случайного дефекта реализации не сломалась бы
> совместимость по Provides: с остальными дистрибутивами.

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

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Tue, Sep 22, 2020 at 09:46:51PM +0300, Vitaly Lipatov wrote:
> > Еще хотел бы подчеркнуть, что стоило бы не изобретать велосипед,
> > а взять готовый код
> > # RPM python dependency generator, using .egg-info/.egg-link/.dist-info
> > data
> > pythondistdeps.py --provides --normalized-names-format pep503
> > 
> > чтобы из-за случайного дефекта реализации не сломалась бы
> > совместимость по Provides: с остальными дистрибутивами.
> 
> Я правильно понимаю, что это ход к тому, чтобы уйти от автогенерируемых
> зависимостей на модули, и держаться тех зависимостей, которые указаны
> разработчиком? Было бы очень неплохо, особенно если сделать обновление
> зависимостей в спеке на основе данных из проекта.

Как понимаю, эти две системы зависимостей не мешают друг другу.
Кроме того, pythonXdist зависимости удобнее для BuildRequires:
а наши автоматичесике зависимости удобнее, чтобы отслеживать
косяки за апстримом.
Хорошо иметь и то, и другое.

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Tue, Sep 22, 2020 at 09:52:53PM +0300, Igor Vlasenko wrote:
> Как понимаю, эти две системы зависимостей не мешают друг другу.
> Кроме того, pythonXdist зависимости удобнее для BuildRequires:
> а наши автоматичесике зависимости удобнее, чтобы отслеживать
> косяки за апстримом.
> Хорошо иметь и то, и другое.

Это две системы зависимостей - по каноническому имени проекта
(можно получить из setup.py)
и по именам используемых модулей
(можно получить анализом директив include)

Проводя аналогию с perl.
Есть пакет CPAN с каноническим именем libwww-perl.
Зависимость на него можно выписать как 
BuildRequires: perl5dist(libwww-perl) (по имени) или
BuildRequires: perl(LWP.pm) (по модулю).

Для perl не нужно особого Provides, вида perl5dist(CPAN name)
потому что все 30.000 пакетов perl называются perl-<CPAN name>,
за исключением 24-х исторически сложившихся исключений.
Поэтому в 99.99% случаев можно вместо perl5dist(CPAN name) писать просто
perl-{CPAN name}.

С python хуже. Можно глазами прочитать setup.py,
но просто написать BuildRequires: python3-module-<normalized name>
не выйдет в большинстве случаев.
Нужно руками сопоставлять <normalized name> и <rpm name>.
Наличие python3dist provides позволило бы 
1) облегчить жизнь при создании нового пакета
2) использовать инструменты автогенерации BR: по setup.py.
3) доп. уровень совместимости со сторонними пакетами.

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 22.09.2020 22:28, Igor Vlasenko wrote:
> On Tue, Sep 22, 2020 at 09:52:53PM +0300, Igor Vlasenko wrote:
>> Как понимаю, эти две системы зависимостей не мешают друг другу.
>> Кроме того, pythonXdist зависимости удобнее для BuildRequires:
>> а наши автоматичесике зависимости удобнее, чтобы отслеживать
>> косяки за апстримом.
>> Хорошо иметь и то, и другое.
> Это две системы зависимостей - по каноническому имени проекта
> (можно получить из setup.py)
> и по именам используемых модулей
> (можно получить анализом директив include)
>
> Проводя аналогию с perl.
> Есть пакет CPAN с каноническим именем libwww-perl.
> Зависимость на него можно выписать как
> BuildRequires: perl5dist(libwww-perl) (по имени) или
> BuildRequires: perl(LWP.pm) (по модулю).
>
> Для perl не нужно особого Provides, вида perl5dist(CPAN name)
> потому что все 30.000 пакетов perl называются perl-<CPAN name>,
> за исключением 24-х исторически сложившихся исключений.
> Поэтому в 99.99% случаев можно вместо perl5dist(CPAN name) писать просто
> perl-{CPAN name}.
>
> С python хуже. Можно глазами прочитать setup.py,
> но просто написать BuildRequires: python3-module-<normalized name>
> не выйдет в большинстве случаев.
> Нужно руками сопоставлять <normalized name> и <rpm name>.
> Наличие python3dist provides позволило бы
> 1) облегчить жизнь при создании нового пакета
> 2) использовать инструменты автогенерации BR: по setup.py.
> 3) доп. уровень совместимости со сторонними пакетами.
>
Мне эта идея нравится.

Кто реализует ?

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 08:52:35AM +0300, Anton Farygin wrote:
> Мне эта идея нравится.
> 
> Кто реализует ?

Я могу, после того, как закончу с perl.

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Tue, Sep 22, 2020 at 08:06:01PM +0300, Igor Vlasenko wrote:
> Уважаемые господа,
> 
> Обсуждал с rider@ недостаточный охват python* пакетов сервисом watch,
> вспомнил, что там не хватает сервиса pypi watch, 
> а написать его мешает тот факт, что у нас 
> до сих пор не реализованы канонические имена 
> для исходных питоньих модулей.
> Так называемые "normalized names"
> сначала https://www.python.org/dev/peps/pep-0503/
> потом https://www.python.org/dev/peps/pep-0566/
> 
> В rpm-based дистрибутивах (SuSE,Mandriva,Fedora) уже сложился
> стандарт их применения:
> 1) в бинарных файлах есть pythonNNdist(normalizedname) Provides.
> Пример из OpenSuSE:
> $ rpmquery --provides -p python3-ZEO-5.2.1-3.5.noarch.rpm | grep dist
> python3.8dist(zeo) = 5.2.1
> python3dist(zeo) = 5.2.1
> 
> И что хорошо, normalized names в пакет руками добавлять не нужно.
> Эти имена используются в egg-info, их легко получить оттуда.
> если добавить в rpm-build-pythonN pythonNdist.prov,
> который будет генерировать Provides: python3dist(normalizedname).
> При чем готовый код для prov можно подсмотреть из той же Fedora.
> 
> 2) рекомендовать называть пакет
> pythonN-module-normalizedname.

А не лучше ли вместо этих балластных provides, как в вашем примере из
OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
называться python3-module-normalizedname?

> А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
> может быть упакетван как
> python3-module-foo
> python3-module-pyfoo
> python3-module-Foo
> python3-module-PyFoo

А какова сейчас в Сизифе доля неправильно названных пакетов для python3?


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:

[...]
> А не лучше ли вместо этих балластных provides, как в вашем примере из
> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> называться python3-module-normalizedname?
Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей 
сборочницы.

[...]

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 09:30:40AM +0300, Dmitry V. Levin wrote:
> 
> А не лучше ли вместо этих балластных provides, как в вашем примере из
> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> называться python3-module-normalizedname?

для perl-* пакетов это не было достигнуто,
хотя думаю, что стоит все-таки правильно переименовать тот же
perl-Template в perl-Template-Toolkit.
Но, к примеру, стоит ли переименовывать исторически сложившиеся
perl-ldap -> perl-perl-ldap
perl-libintl -> perl-libintl-perl
perl-MIDI -> perl-MIDI-Perl
или утилиты
perlconsole -> perl-perlconsole
sdf -> perl-sdf
txt2html -> perl-txt2html ?
Это будет эстетически некрасиво.

с питоном так же. <normalized name> может быть
относительно уродливо по сравнению с именем проекта на PyPi.
 
> > А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
> > может быть упакетван как
> > python3-module-foo
> > python3-module-pyfoo
> > python3-module-Foo
> > python3-module-PyFoo
> 
> А какова сейчас в Сизифе доля неправильно названных пакетов для python3?

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

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 09:48:34AM +0300, Igor Vlasenko wrote:
> с питоном так же. <normalized name> может быть
> относительно уродливо по сравнению с именем проекта на PyPi.

Поэтому пусть для пользователей имя пакета будет человекочитаемое, 
им имя проекта более родное,
а машинно генерируемое <normalized name> пусть будет для Provides
и (Build)Requires, скрытое от взгляда.


-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 09:54, Igor Vlasenko wrote:
> On Wed, Sep 23, 2020 at 09:48:34AM +0300, Igor Vlasenko wrote:
>> с питоном так же. <normalized name> может быть
>> относительно уродливо по сравнению с именем проекта на PyPi.
> Поэтому пусть для пользователей имя пакета будет человекочитаемое,
> им имя проекта более родное,
> а машинно генерируемое <normalized name> пусть будет для Provides
> и (Build)Requires, скрытое от взгляда.
>
Да, согласен.

Делать normalized имя для имени пакета часто просто не красиво.

Дополнительных provides на фоне всего остального это добавит не очень 
много, по идее.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Andrey Cherepanov]

23.09.2020 09:39, Sergey V Turchin пишет:
> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
>
> [...]
>> А не лучше ли вместо этих балластных provides, как в вашем примере из
>> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
>> называться python3-module-normalizedname?
> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей 
> сборочницы.
>
Сергей, одно другому противоречит. Поэтому SUSE, которая названия
пакетов в нижний регистр переводит, и придумало такие Provides.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Wed, Sep 23, 2020 at 09:48:34AM +0300, Igor Vlasenko wrote:
 >> с питоном так же. <normalized name> может быть
 >> относительно уродливо по сравнению с именем проекта на PyPi.

 > Поэтому пусть для пользователей имя пакета будет человекочитаемое, 
 > им имя проекта более родное,
 > а машинно генерируемое <normalized name> пусть будет для Provides
 > и (Build)Requires, скрытое от взгляда.

Послушайте, зачем это всё ?
Какая вообще разница, какое имя имеет файл, обычно начинающийся
на pythno3-module, если всё, что от него нужно -- это список
requires/provides вида python3(...) ?
Какому не спятившему окончательно пользователю интересно
рассматривать глазами несколько тысяч таких файлов ? Зачем ?
Зачем нас снова и снова пытаются занять какой-то нелепой
вознёй, когда единственное, что придаёт хоть какой-то смысл
этому нашему с вами дистрибутиву -- это работающие приложения,
и полагаю, что инициаторам этого начинания следует привести
некий бесспорный набор причин, почему такое изменение нас
к этому приблизит.

-- 

Re: [devel] Q: PEP-503/566 normalized names for python?

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 2291 bytes --]

23.09.2020 11:44, Sergey Bolshakov пишет:
>>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:
> 
>  > On Wed, Sep 23, 2020 at 09:48:34AM +0300, Igor Vlasenko wrote:
>  >> с питоном так же. <normalized name> может быть
>  >> относительно уродливо по сравнению с именем проекта на PyPi.
> 
>  > Поэтому пусть для пользователей имя пакета будет человекочитаемое, 
>  > им имя проекта более родное,
>  > а машинно генерируемое <normalized name> пусть будет для Provides
>  > и (Build)Requires, скрытое от взгляда.
> 
> Послушайте, зачем это всё ?

за тем же зачем все эти бессмысленные и беспощадные repocop'ы
для меня ответ прост (Игорь, уж извини)
что делает кот когда ему заняться нечем? ну вы знаете
почему он это делает? потому что может

> Какая вообще разница, какое имя имеет файл, обычно начинающийся
> на pythno3-module, если всё, что от него нужно -- это список
> requires/provides вида python3(...) ?
> Какому не спятившему окончательно пользователю интересно
> рассматривать глазами несколько тысяч таких файлов ? Зачем ?
> Зачем нас снова и снова пытаются занять какой-то нелепой
> вознёй, когда единственное, что придаёт хоть какой-то смысл
> этому нашему с вами дистрибутиву -- это работающие приложения,
> и полагаю, что инициаторам этого начинания следует привести
> некий бесспорный набор причин, почему такое изменение нас
> к этому приблизит.
> 


-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 09:48:34AM +0300, Igor Vlasenko wrote:
> On Wed, Sep 23, 2020 at 09:30:40AM +0300, Dmitry V. Levin wrote:
> > 
> > А не лучше ли вместо этих балластных provides, как в вашем примере из
> > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > называться python3-module-normalizedname?
> 
> для perl-* пакетов это не было достигнуто,
> хотя думаю, что стоит все-таки правильно переименовать тот же
> perl-Template в perl-Template-Toolkit.
> Но, к примеру, стоит ли переименовывать исторически сложившиеся
> perl-ldap -> perl-perl-ldap
> perl-libintl -> perl-libintl-perl
> perl-MIDI -> perl-MIDI-Perl
> или утилиты
> perlconsole -> perl-perlconsole
> sdf -> perl-sdf
> txt2html -> perl-txt2html ?
> Это будет эстетически некрасиво.
> 
> с питоном так же. <normalized name> может быть
> относительно уродливо по сравнению с именем проекта на PyPi.

Имена пакетов интересны depsolver'ам в гораздо большей степени, чем людям.

> > > А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
> > > может быть упакетван как
> > > python3-module-foo
> > > python3-module-pyfoo
> > > python3-module-Foo
> > > python3-module-PyFoo
> > 
> > А какова сейчас в Сизифе доля неправильно названных пакетов для python3?
> 
> На глаз большая, но чтобы точно сосчитать,
> нужно писать достаточно сложный инструмент.

Этот инструмент должен быть проще, чем генератор Provides, если мы пойдём
по этому пути.  Поэтому я думаю, что начинать обсуждение имеет смысл с
этого инструмента и ответа на вопрос о соответствии имён в Сизифе.


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
> Послушайте, зачем это всё ?
> Какая вообще разница, какое имя имеет файл, обычно начинающийся
> на pythno3-module, если всё, что от него нужно -- это список
> requires/provides вида python3(...) ?
> Какому не спятившему окончательно пользователю интересно
> рассматривать глазами несколько тысяч таких файлов ? Зачем ?

Я как раз не выступаю за обязательное переименование пакетов.
Так что в таком контексте я поддерживаю текст выше.
Для меня и Виталия, как понимаю, достаточно автогенерируемых
python3dist(normalized-name)


-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
> On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
> > Послушайте, зачем это всё ?
> > Какая вообще разница, какое имя имеет файл, обычно начинающийся
> > на pythno3-module, если всё, что от него нужно -- это список
> > requires/provides вида python3(...) ?
> > Какому не спятившему окончательно пользователю интересно
> > рассматривать глазами несколько тысяч таких файлов ? Зачем ?
> 
> Я как раз не выступаю за обязательное переименование пакетов.
> Так что в таком контексте я поддерживаю текст выше.
> Для меня и Виталия, как понимаю, достаточно автогенерируемых
> python3dist(normalized-name)

4 тысячи лишних provides - это цена, которую заплатит каждый пользователь
apt, причём не один раз, а при каждом использовании apt.  Для этого нужны
веские основания.


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 13:13, Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
>> On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
>>> Послушайте, зачем это всё ?
>>> Какая вообще разница, какое имя имеет файл, обычно начинающийся
>>> на pythno3-module, если всё, что от него нужно -- это список
>>> requires/provides вида python3(...) ?
>>> Какому не спятившему окончательно пользователю интересно
>>> рассматривать глазами несколько тысяч таких файлов ? Зачем ?
>> Я как раз не выступаю за обязательное переименование пакетов.
>> Так что в таком контексте я поддерживаю текст выше.
>> Для меня и Виталия, как понимаю, достаточно автогенерируемых
>> python3dist(normalized-name)
> 4 тысячи лишних provides - это цена, которую заплатит каждый пользователь
> apt, причём не один раз, а при каждом использовании apt.  Для этого нужны
> веские основания.
>
>
но это всего 0.5349674806642691  от общего числа provides пакетов 
Sisyphus на сегодняшнее утро.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 13:24, Anton Farygin wrote:
> On 23.09.2020 13:13, Dmitry V. Levin wrote:
>> On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
>>> On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
>>>> Послушайте, зачем это всё ?
>>>> Какая вообще разница, какое имя имеет файл, обычно начинающийся
>>>> на pythno3-module, если всё, что от него нужно -- это список
>>>> requires/provides вида python3(...) ?
>>>> Какому не спятившему окончательно пользователю интересно
>>>> рассматривать глазами несколько тысяч таких файлов ? Зачем ?
>>> Я как раз не выступаю за обязательное переименование пакетов.
>>> Так что в таком контексте я поддерживаю текст выше.
>>> Для меня и Виталия, как понимаю, достаточно автогенерируемых
>>> python3dist(normalized-name)
>> 4 тысячи лишних provides - это цена, которую заплатит каждый 
>> пользователь
>> apt, причём не один раз, а при каждом использовании apt.  Для этого 
>> нужны
>> веские основания.
>>
>>
> но это всего 0.5349674806642691  от общего числа provides пакетов 
> Sisyphus на сегодняшнее утро.
>
0.5349674806642691%

Re: [devel] Q: PEP-503/566 normalized names for python?

[Andrey Savchenko]

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

On Wed, 23 Sep 2020 13:13:05 +0300 Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
> > On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
> > > Послушайте, зачем это всё ?
> > > Какая вообще разница, какое имя имеет файл, обычно начинающийся
> > > на pythno3-module, если всё, что от него нужно -- это список
> > > requires/provides вида python3(...) ?
> > > Какому не спятившему окончательно пользователю интересно
> > > рассматривать глазами несколько тысяч таких файлов ? Зачем ?
> > 
> > Я как раз не выступаю за обязательное переименование пакетов.
> > Так что в таком контексте я поддерживаю текст выше.
> > Для меня и Виталия, как понимаю, достаточно автогенерируемых
> > python3dist(normalized-name)
> 
> 4 тысячи лишних provides - это цена, которую заплатит каждый пользователь
> apt, причём не один раз, а при каждом использовании apt.  Для этого нужны
> веские основания.

Если для apt проблемно обработать каких-то несколько тысяч
дополнительных зависимостей то, возможно, сделает поработать над
оптимизацией apt?

Пока что это выглядит как «уши нужно отрезать, потому что шапка не
налазит».

Best regards,
Andrew Savchenko

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

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 12:21, Dmitry V. Levin wrote:
>>>> А то у нас бардак. Проект с именем PyFoo и normalized name pyfoo
>>>> может быть упакетван как
>>>> python3-module-foo
>>>> python3-module-pyfoo
>>>> python3-module-Foo
>>>> python3-module-PyFoo
>>> А какова сейчас в Сизифе доля неправильно названных пакетов для python3?
>> На глаз большая, но чтобы точно сосчитать,
>> нужно писать достаточно сложный инструмент.
> Этот инструмент должен быть проще, чем генератор Provides, если мы пойдём
> по этому пути.  Поэтому я думаю, что начинать обсуждение имеет смысл с
> этого инструмента и ответа на вопрос о соответствии имён в Сизифе.

А есть какой-то способ узнать не заглядывая внутрь egg, правильное ли 
имя у пакета ?

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 01:13:05PM +0300, Dmitry V. Levin wrote:
> 4 тысячи лишних provides - это цена, которую заплатит каждый пользователь
> apt, причём не один раз, а при каждом использовании apt.  Для этого нужны
> веские основания.

Гм. На фоне наших имеющихся расточительных python2/3(...) Provides,
которых 108 тысяч 500, 4 тысячи погоды не сделают.
Это капля в море.

если же с индексами apt такие проблемы,
то переход с сотен тысяч pythonX(...) Provides/Requires
на тысячи python3dist Prov/Requires
помог бы решить проблему с apt, стань там проблема критичной.



-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 13:13, Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
>> On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
>>> Послушайте, зачем это всё ?
>>> Какая вообще разница, какое имя имеет файл, обычно начинающийся
>>> на pythno3-module, если всё, что от него нужно -- это список
>>> requires/provides вида python3(...) ?
>>> Какому не спятившему окончательно пользователю интересно
>>> рассматривать глазами несколько тысяч таких файлов ? Зачем ?
>> Я как раз не выступаю за обязательное переименование пакетов.
>> Так что в таком контексте я поддерживаю текст выше.
>> Для меня и Виталия, как понимаю, достаточно автогенерируемых
>> python3dist(normalized-name)
> 4 тысячи лишних provides - это цена, которую заплатит каждый пользователь
> apt, причём не один раз, а при каждом использовании apt.  Для этого нужны
> веские основания.

Добавлю, что почему-то никого не смущает наличие у пакетов 13090 
зависимостей на /bin/sh

173811 зависимостей на rpmlib(PayloadIsLzma)
41405 зависимостей на rpmlib(SetVersions)
41861 зависимостей на rtld(GNU_HASH)


Проще вот так:

"rpmlib(PayloadIsLzma)",115483
"rtld(GNU_HASH)",41861
"rpmlib(SetVersions)",41405
"libc.so.6(GLIBC_2.4)",19479
"libc.so.6(GLIBC_2.17)(64bit)",17356
"/bin/sh",13090
"libc.so.6(GLIBC_2.0)",12994
"libc.so.6(GLIBC_2.1.3)",11391
"libc.so.6(GLIBC_2.2.5)(64bit)",8757
"libc.so.6(GLIBC_2.3.4)",8548
"libstdc++.so.6(GLIBCXX_3.4)(64bit)",8206
"libstdc++.so.6(CXXABI_1.3)(64bit)",8129
"libc.so.6(GLIBC_2.4)(64bit)",7826
"ld-linux-aarch64.so.1()(64bit)",7503
"ld-linux-aarch64.so.1(GLIBC_2.17)(64bit)",7500
"libc.so.6(GLIBC_2.1)",6892
"ld-linux-armhf.so.3",6847
"ld-linux-armhf.so.3(GLIBC_2.4)",6821
"libstdc++.so.6(GLIBCXX_3.4)",6740
"libgcc_s.so.1(GCC_3.0)(64bit)",6707
"libstdc++.so.6(CXXABI_1.3)",6676
"/lib/ld-linux.so.2",6523
"libc.so.6(GLIBC_2.7)",6416
"coreutils",5938
"libglib-2.0.so.0()(64bit)",5882
"libc.so.6(GLIBC_2.14)(64bit)",5832
"libc.so.6(GLIBC_2.3.4)(64bit)",5819
"/lib64/ld-linux-x86-64.so.2",5612
"/lib64/ld64.so.2",5346
"/lib64/ld-linux-aarch64.so.1",5251
"libpthread.so.0(GLIBC_2.17)(64bit)",5219
"/usr/lib64/pkgconfig",5171
"libglib-2.0.so.0",4957
"libgobject-2.0.so.0()(64bit)",4903
"libm.so.6(GLIBC_2.17)(64bit)",4691
"libstdc++.so.6(CXXABI_1.3.9)(64bit)",4686
"/lib/ld-linux-armhf.so.3",4659
"libstdc++.so.6(GLIBCXX_3.4.21)(64bit)",4635
"libc.so.6(GLIBC_2.3)",4599
"libpthread.so.0(GLIBC_2.0)",4421
"libgobject-2.0.so.0",4147
"rtld(GNU_UNIQUE)",4132
"libc.so.6(GLIBC_2.2)",4048
"libm.so.6(GLIBC_2.0)",3830
"libQt5Core.so.5()(64bit)",3721
"libgcc_s.so.1(GCC_3.0)",3632
"libstdc++.so.6(GLIBCXX_3.4.9)(64bit)",3556
"libstdc++.so.6(CXXABI_1.3.9)",3544
"libstdc++.so.6(GLIBCXX_3.4.21)",3539
"/usr/lib/pkgconfig",3346

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 01:28:15PM +0300, Anton Farygin wrote:
> А есть какой-то способ узнать не заглядывая внутрь egg, правильное ли имя у
> пакета ?

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

поэтому
ls python3-module-*[A-Z_]*alt*
даст примеры

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 13:37, Anton Farygin wrote:
> On 23.09.2020 13:13, Dmitry V. Levin wrote:
>> On Wed, Sep 23, 2020 at 01:07:58PM +0300, Igor Vlasenko wrote:
>>> On Wed, Sep 23, 2020 at 11:44:11AM +0300, Sergey Bolshakov wrote:
>>>> Послушайте, зачем это всё ?
>>>> Какая вообще разница, какое имя имеет файл, обычно начинающийся
>>>> на pythno3-module, если всё, что от него нужно -- это список
>>>> requires/provides вида python3(...) ?
>>>> Какому не спятившему окончательно пользователю интересно
>>>> рассматривать глазами несколько тысяч таких файлов ? Зачем ?
>>> Я как раз не выступаю за обязательное переименование пакетов.
>>> Так что в таком контексте я поддерживаю текст выше.
>>> Для меня и Виталия, как понимаю, достаточно автогенерируемых
>>> python3dist(normalized-name)
>> 4 тысячи лишних provides - это цена, которую заплатит каждый 
>> пользователь
>> apt, причём не один раз, а при каждом использовании apt.  Для этого 
>> нужны
>> веские основания.
>
> Добавлю, что почему-то никого не смущает наличие у пакетов 13090 
> зависимостей на /bin/sh
>
> 173811 зависимостей на rpmlib(PayloadIsLzma)
> 41405 зависимостей на rpmlib(SetVersions)
> 41861 зависимостей на rtld(GNU_HASH)

Ещё немного занимательной статистики:

первое поле - имя пакета, второе - provides, третье - length от версии 
этого provides в байтах. Первые 50 по уменьшению:

"ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",349758
"ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",349706
"ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",348083
"i586-ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",250264
"ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",250264
"ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",250230
"ardour","/usr/lib/ardour6/libardour.so.3",180075
"i586-ardour","/usr/lib/ardour6/libardour.so.3",180075
"ardour","/usr/lib/ardour6/libardour.so.3",179997
"ardour","/usr/lib64/ardour6/libardour.so.3()(64bit)",179924
"ardour","/usr/lib64/ardour6/libardour.so.3()(64bit)",179890
"ardour","/usr/lib64/ardour6/libardour.so.3()(64bit)",179878
"ghc8.6.4-texmath","libHStexmath-0.12.0.2-K18FO15EXTwC3mU4i8PUsJ-ghc8.6.4.so",171558
"ghc8.6.4-texmath","libHStexmath-0.12.0.2-K18FO15EXTwC3mU4i8PUsJ-ghc8.6.4.so()(64bit)",171555
"ghc8.6.4-texmath","libHStexmath-0.12.0.2-K18FO15EXTwC3mU4i8PUsJ-ghc8.6.4.so()(64bit)",171479
"ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so()(64bit)",164071
"ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so",163531
"ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so()(64bit)",161626
"libgdal","libgdal.so.26()(64bit)",148813
"libgdal","libgdal.so.26()(64bit)",148717
"libgdal","libgdal.so.26()(64bit)",148701
"libgdal","libgdal.so.26",148335
"libgdal","libgdal.so.26",148320
"i586-libgdal","libgdal.so.26",148320
"ghc8.6.4-texmath","libHStexmath-0.12.0.2-HK8B58fGjJX9rq7pWBVrYD-ghc8.6.4.so()(64bit)",147020
"i586-ghc8.6.4-texmath","libHStexmath-0.12.0.2-HK8B58fGjJX9rq7pWBVrYD-ghc8.6.4.so",147003
"ghc8.6.4-texmath","libHStexmath-0.12.0.2-HK8B58fGjJX9rq7pWBVrYD-ghc8.6.4.so",147003
"ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so()(64bit)",114796
"ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so",114477
"i586-ghc8.6.4","libHSCabal-2.4.0.1-ghc8.6.4.so",114477
"libgo11","libgo.so.11",108574
"i586-libgo11","libgo.so.11",108574
"libgo11","libgo.so.11()(64bit)",108160
"ghc8.6.4","libHSbase-4.12.0.0-ghc8.6.4.so",100490
"ghc8.6.4","libHSbase-4.12.0.0-ghc8.6.4.so()(64bit)",100198
"ghc8.6.4","libHSbase-4.12.0.0-ghc8.6.4.so()(64bit)",99196
"i586-libgo14","libgo.so.14",80425
"libgo14","libgo.so.14",80425
"libgo14","libgo.so.14()(64bit)",79682
"libgo13","libgo.so.13",78213
"i586-libgo13","libgo.so.13",78213
"libgo13","libgo.so.13()(64bit)",77471
"i586-libvxl2","libvnl.so.2",77403
"libvxl2","libvnl.so.2",77403
"libvxl2","libvnl.so.2",77401
"libvxl2","libvnl.so.2()(64bit)",77394
"libvxl2","libvnl.so.2()(64bit)",77371
"libvxl2","libvnl.so.2()(64bit)",77371
"i586-ghc8.6.4","libHSbase-4.12.0.0-ghc8.6.4.so",75160
"ghc8.6.4","libHSbase-4.12.0.0-ghc8.6.4.so",75160

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 01:27:22PM +0300, Andrey Savchenko wrote:
[...]
> Если для apt проблемно обработать каких-то несколько тысяч
> дополнительных зависимостей то, возможно, сделает поработать над
> оптимизацией apt?

Возможно.  Поработайте.

> Пока что это выглядит как «уши нужно отрезать, потому что шапка не
> налазит».

Пока это выглядит как "а нам точно нужен ещё один комплект ушей?".

On Wed, Sep 23, 2020 at 01:33:32PM +0300, Igor Vlasenko wrote:
> Гм. На фоне наших имеющихся расточительных python2/3(...) Provides,
> которых 108 тысяч 500, 4 тысячи погоды не сделают.
> Это капля в море.

Вы замеряли?  Я нет.  Может сделают, а может и нет.
Кто предлагает изменение, тому следует оценить последствия,
как +, так и -.

> если же с индексами apt такие проблемы,
> то переход с сотен тысяч pythonX(...) Provides/Requires
> на тысячи python3dist Prov/Requires
> помог бы решить проблему с apt, стань там проблема критичной.

Нынешние python3() Provides/Requires is here to stay, о переходе речи не идёт.

On Wed, Sep 23, 2020 at 01:37:47PM +0300, Anton Farygin wrote:
> Добавлю, что почему-то никого не смущает наличие у пакетов 13090 
> зависимостей на /bin/sh
> 
> 173811 зависимостей на rpmlib(PayloadIsLzma)
> 41405 зависимостей на rpmlib(SetVersions)
> 41861 зависимостей на rtld(GNU_HASH)

Может быть, кого-то смущает.
Кстати, это Requires, или Provides?


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 14:19, Dmitry V. Levin wrote:
>> Добавлю, что почему-то никого не смущает наличие у пакетов 13090
>> зависимостей на /bin/sh
>>
>> 173811 зависимостей на rpmlib(PayloadIsLzma)
>> 41405 зависимостей на rpmlib(SetVersions)
>> 41861 зависимостей на rtld(GNU_HASH)
> Может быть, кого-то смущает.
> Кстати, это Requires, или Provides?

Это requires.

Меня смущает то, что наличие этих requires мешает сделать provides у 
других пакетов.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 02:21:18PM +0300, Anton Farygin wrote:
> On 23.09.2020 14:19, Dmitry V. Levin wrote:
> >> Добавлю, что почему-то никого не смущает наличие у пакетов 13090
> >> зависимостей на /bin/sh
> >>
> >> 173811 зависимостей на rpmlib(PayloadIsLzma)
> >> 41405 зависимостей на rpmlib(SetVersions)
> >> 41861 зависимостей на rtld(GNU_HASH)
> > Может быть, кого-то смущает.
> > Кстати, это Requires, или Provides?
> 
> Это requires.

Provides и Requires обрабатываются немного по-разному.

Когда кто-то предлагает влить в репозиторий 1% (или сколько их там на
самом деле) лишних Provides, я ожидаю как минимум честной оценки
последствий.


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 14:26, Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 02:21:18PM +0300, Anton Farygin wrote:
>> On 23.09.2020 14:19, Dmitry V. Levin wrote:
>>>> Добавлю, что почему-то никого не смущает наличие у пакетов 13090
>>>> зависимостей на /bin/sh
>>>>
>>>> 173811 зависимостей на rpmlib(PayloadIsLzma)
>>>> 41405 зависимостей на rpmlib(SetVersions)
>>>> 41861 зависимостей на rtld(GNU_HASH)
>>> Может быть, кого-то смущает.
>>> Кстати, это Requires, или Provides
>> Это requires.
> Provides и Requires обрабатываются немного по-разному.

В соседнем письме я привёл пример provides с большими версиями. В 
принципе, если зачистить пару таких пакетов, то можно будет наскрести 
эти самые 800 килобайт лишних provides.

У тебя есть идеи как такую оценку влияния provides может сделать тот, 
кто предложил ?

>
> Когда кто-то предлагает влить в репозиторий 1% (или сколько их там на
> самом деле) лишних Provides, я ожидаю как минимум честной оценки
> последствий.
>
>
На самом деле их конечно меньше 1%. Скорее к 0.1%

Т.е. - последствия будут скорее всего незаметны. В сизифе всего 1577 
пакетов, имя которых начинается с python3-module

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 14:32, Anton Farygin wrote:
>
> Т.е. - последствия будут скорее всего незаметны. В сизифе всего 1577 
> пакетов, имя которых начинается с python3-module 

Исходных пакета. бинарных 3792.

А бывают ли provides только у исходных пакетов ?

Re: [devel] Q: PEP-503/566 normalized names for python?

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 02:34:53PM +0300, Anton Farygin wrote:
> On 23.09.2020 14:32, Anton Farygin wrote:
> >
> > Т.е. - последствия будут скорее всего незаметны. В сизифе всего 1577 
> > пакетов, имя которых начинается с python3-module 
> 
> Исходных пакета. бинарных 3792.

$ cut -f1 Sisyphus/files/list/bin.list |sort -u |grep -c '^python3-module-'
3787

> А бывают ли provides только у исходных пакетов ?

Первый раз слышу, чтобы у исходных пакетов были Provides,
хотя технически это, наверное, возможно.


-- 
ldv

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 23.09.2020 14:40, Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 02:34:53PM +0300, Anton Farygin wrote:
>> On 23.09.2020 14:32, Anton Farygin wrote:
>>> Т.е. - последствия будут скорее всего незаметны. В сизифе всего 1577
>>> пакетов, имя которых начинается с python3-module
>> Исходных пакета. бинарных 3792.
> $ cut -f1 Sisyphus/files/list/bin.list |sort -u |grep -c '^python3-module-'
> 3787
Спасибо, гляну откуда берётся эта разница.
>
>> А бывают ли provides только у исходных пакетов ?
> Первый раз слышу, чтобы у исходных пакетов были Provides,
> хотя технически это, наверное, возможно.
>
>
нет, фокус не получится. Если этот provides надо вычислить из egg файла, 
то в src.rpm его уже не записать.

остаётся только и дальше грузить apt.

с Provides, кстати, тоже есть явные ошибки.

имя provides,версия,количество в репозитории (x86_64 + noarch):

"fontlang(en)","",356
"fontlang(ru)","",229
"/usr/bin/jar","",194
"fontlang(be)","",153
"fontlang(uk)","",129
"fontlang(ja)","",60
"fontlang(ko)","",56
"fontlang(ber-dz)","",50
"aspell-dictionary","",39
"fontlang(zh-tw)","",35
"fontlang(zh-sg)","",30
"festvox","",29
"fontlang(zh-cn)","",29
"fontlang(th)","",27
"deprecated()","",26
"fontlang(kok)","",20
"fontlang(zh-hk)","",16
"fontlang(zh-mo)","",16
"kacst-fonts","2.0-alt3_18",15
"webclient","",14
"ispell-dictionary","",13
"moc-decoder-plugin","",10
"licq-plugin","",10
"xvt","",9
"indexhtml-Desktop","1:5.0",8
"design-alterator","",8
"design-graphics","12.0.0",8
"alsaplayer-in-plugin","0.99.80-alt11.3",8
"/etc/alterator/design-browser-qt","50",8
"osgi(org.apache.lucene.analyzers)","7.7.0",8
"osgi(org.apache.lucene.analyzers)","5.5.0",8
"MTA","",8
"alsaplayer-input-plugin","0.99.80-alt11.3",8
"indexhtml","",8
"alterator-icons","",8
"fontlang(ber-ma)","",7
"/usr/share/design-current","000012000000",6
"imsettings-desktop-module","1.8.2-alt1_1",6
"smtpdaemon","",6
"python3(facebook)","",6
"boost-math","1:1.74.0-alt1",6
"alsaplayer-out-plugin","0.99.80-alt11.3",6
"festival-voice","",6
"boost-math","1:1.73.0-alt4",6
"alsaplayer-output-plugin","0.99.80-alt11.3",6
"/usr/share/design/current","000012000000",6
"postgresql-tcl","",6
"emacs","26.3-alt12",5
"mnogosearch-backend","3.3.14",5
"emacsen","",5

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladimir D. Seleznev]

On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> 
> [...]
> > А не лучше ли вместо этих балластных provides, как в вашем примере из
> > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > называться python3-module-normalizedname?
> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей 
> сборочницы.

Почему? Я бы лучше сделал проверку на совпадения в именах пакетов не
чувствительной к регистру.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Wednesday, 23 September 2020 18:40:39 MSK Vladimir D wrote:
> On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> > On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> > 
> > [...]
> > 
> > > А не лучше ли вместо этих балластных provides, как в вашем примере из
> > > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > > называться python3-module-normalizedname?
> > 
> > Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> > сборочницы.
> 
> Почему?
чТОбы бЫло КраСиВО. Ну, И Оно Не Для Красивого Чтения, а чтобы всё было 
однообразно.

> Я бы лучше сделал проверку на совпадения в именах пакетов не
> чувствительной к регистру.
Это больше на бардак похоже, т.к. появится ещё один вид вычисления весов 
пакетов. Мы ещё от disttag до конца не оправились.

-- 
Regards, Sergey.

Re: [devel] предложение всем, кто предлагает изменения

[Dmitry V. Levin]

On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> 
> [...]
> > А не лучше ли вместо этих балластных provides, как в вашем примере из
> > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > называться python3-module-normalizedname?
> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей 
> сборочницы.

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

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

Спасибо,


-- 
ldv

Re: [devel] предложение всем, кто предлагает изменения

[Anton Farygin]

On 24.09.2020 12:09, Dmitry V. Levin wrote:
> On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
>> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
>>
>> [...]
>>> А не лучше ли вместо этих балластных provides, как в вашем примере из
>>> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
>>> называться python3-module-normalizedname?
>> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
>> сборочницы.
> Я предлагаю всем, кто предлагает изменения, затрагивающие других людей,
> сопровождать свои изменения оценкой последствий, в том числе оценкой того,
> кого и чего конкретно затрагивают предлагаемые изменения, и оценкой
> трудозатрат по реализации и поддержке предлагаемых изменений.
>
> Это позволит, с одной стороны, уменьшить количество плохо проработанных
> предложений, и, с другой стороны, увеличить шанс сделать информированный
> выбор в пользу того или иного предложения.
>
Дим, мне так вполне очевидно то, что сделавший такое предложение не 
сможет просчитать трудозатраты по реализации и поддержке таких изменений.

Банально просто потому что он не знает и не может знать, насколько 
тяжело то или иное предложение реализуется.

Кстати, по поводу реализуется - у нас есть где-то документ с описанием 
архитектуры сборочной системы ?
Я видел только описание TASK в исходниках, а вот примерный developer 
guide для girar - нет.

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

Re: [devel] предложение всем, кто предлагает изменения

[Dmitry V. Levin]

On Thu, Sep 24, 2020 at 02:08:47PM +0300, Anton Farygin wrote:
> On 24.09.2020 12:09, Dmitry V. Levin wrote:
> > On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> >> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> >>
> >> [...]
> >>> А не лучше ли вместо этих балластных provides, как в вашем примере из
> >>> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> >>> называться python3-module-normalizedname?
> >> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> >> сборочницы.
> > Я предлагаю всем, кто предлагает изменения, затрагивающие других людей,
> > сопровождать свои изменения оценкой последствий, в том числе оценкой того,
> > кого и чего конкретно затрагивают предлагаемые изменения, и оценкой
> > трудозатрат по реализации и поддержке предлагаемых изменений.
> >
> > Это позволит, с одной стороны, уменьшить количество плохо проработанных
> > предложений, и, с другой стороны, увеличить шанс сделать информированный
> > выбор в пользу того или иного предложения.
> >
> Дим, мне так вполне очевидно то, что сделавший такое предложение не 
> сможет просчитать трудозатраты по реализации и поддержке таких изменений.
> 
> Банально просто потому что он не знает и не может знать, насколько 
> тяжело то или иное предложение реализуется.

Зависит от предложения.  Вот, например, если предлагается запретить
заглавные буквы в именах любых пакетов, то сложность реализации зависит от
- сложности реализации самого запрета (видимо, проверки в sisyphus_check);
- сложность адаптации уже существующих пакетов к новым правилам.


-- 
ldv

Re: [devel] предложение всем, кто предлагает изменения

[Anton Farygin]

On 24.09.2020 14:43, Dmitry V. Levin wrote:
> On Thu, Sep 24, 2020 at 02:08:47PM +0300, Anton Farygin wrote:
>> On 24.09.2020 12:09, Dmitry V. Levin wrote:
>>> On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
>>>> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
>>>>
>>>> [...]
>>>>> А не лучше ли вместо этих балластных provides, как в вашем примере из
>>>>> OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
>>>>> называться python3-module-normalizedname?
>>>> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
>>>> сборочницы.
>>> Я предлагаю всем, кто предлагает изменения, затрагивающие других людей,
>>> сопровождать свои изменения оценкой последствий, в том числе оценкой того,
>>> кого и чего конкретно затрагивают предлагаемые изменения, и оценкой
>>> трудозатрат по реализации и поддержке предлагаемых изменений.
>>>
>>> Это позволит, с одной стороны, уменьшить количество плохо проработанных
>>> предложений, и, с другой стороны, увеличить шанс сделать информированный
>>> выбор в пользу того или иного предложения.
>>>
>> Дим, мне так вполне очевидно то, что сделавший такое предложение не
>> сможет просчитать трудозатраты по реализации и поддержке таких изменений.
>>
>> Банально просто потому что он не знает и не может знать, насколько
>> тяжело то или иное предложение реализуется.
> Зависит от предложения.  Вот, например, если предлагается запретить
> заглавные буквы в именах любых пакетов, то сложность реализации зависит от
> - сложности реализации самого запрета (видимо, проверки в sisyphus_check);
> - сложность адаптации уже существующих пакетов к новым правилам.
>
>
да, и нужно ещё подсчитать, сколько новых provides/obsoletes появится, и 
насколько процентов станет тяжелее apt'у от этого решения.

Re: [devel] предложение всем, кто предлагает изменения

[Sergey V Turchin]

On Thursday, 24 September 2020 14:43:04 MSK Dmitry V wrote:

[...]
> Зависит от предложения.  Вот, например, если предлагается запретить
> заглавные буквы в именах любых пакетов, то сложность реализации зависит от
> - сложности реализации самого запрета (видимо, проверки в sisyphus_check);
Минимальная.

> - сложность адаптации уже существующих пакетов к новым правилам.
Лёгкая. Лишь немного мата в мой адрес. ;-)

-- 
Regards, Sergey.

Re: [devel] предложение всем, кто предлагает изменения

[Sergey V Turchin]

On Thursday, 24 September 2020 14:53:50 MSK Anton Farygin wrote:

[...]
> > Зависит от предложения.  Вот, например, если предлагается запретить
> > заглавные буквы в именах любых пакетов, то сложность реализации зависит от
> > - сложности реализации самого запрета (видимо, проверки в sisyphus_check);
> > - сложность адаптации уже существующих пакетов к новым правилам.
> 
> да, и нужно ещё подсчитать,
Это и без подсчётов можно.

> сколько новых provides/obsoletes появится, и
500

> насколько процентов станет тяжелее apt'у от этого решения.
0.02% ;-)

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladimir D. Seleznev]

On Thu, Sep 24, 2020 at 10:58:38AM +0300, Sergey V Turchin wrote:
> On Wednesday, 23 September 2020 18:40:39 MSK Vladimir D wrote:
> > On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> > > On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> > > 
> > > [...]
> > > 
> > > > А не лучше ли вместо этих балластных provides, как в вашем примере из
> > > > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > > > называться python3-module-normalizedname?
> > > 
> > > Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> > > сборочницы.
> > 
> > Почему?
> чТОбы бЫло КраСиВО. Ну, И Оно Не Для Красивого Чтения, а чтобы всё было 
> однообразно.
> 
> > Я бы лучше сделал проверку на совпадения в именах пакетов не
> > чувствительной к регистру.
> Это больше на бардак похоже, т.к. появится ещё один вид вычисления весов 
> пакетов. Мы ещё от disttag до конца не оправились.

Не бардак, а порядок. И при чём тут вычисления весов и disttag? Если
будет такая проверка, то в репозитории не смогут одновременно находиться
пакеты с именами FooBar и foobar. Эта проверка не про rpm и не про apt.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Thursday, 24 September 2020 16:57:44 MSK Vladimir D wrote:
> On Thu, Sep 24, 2020 at 10:58:38AM +0300, Sergey V Turchin wrote:
> > On Wednesday, 23 September 2020 18:40:39 MSK Vladimir D wrote:
> > > On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> > > > On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > А не лучше ли вместо этих балластных provides, как в вашем примере
> > > > > из
> > > > > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > > > > называться python3-module-normalizedname?
> > > > 
> > > > Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> > > > сборочницы.
> > > 
> > > Почему?
> > 
> > чТОбы бЫло КраСиВО. Ну, И Оно Не Для Красивого Чтения, а чтобы всё было
> > однообразно.
> > 
> > > Я бы лучше сделал проверку на совпадения в именах пакетов не
> > > чувствительной к регистру.
> > 
> > Это больше на бардак похоже, т.к. появится ещё один вид вычисления весов
> > пакетов. Мы ещё от disttag до конца не оправились.
> 
> Не бардак, а порядок.
Бардак порядком можно назвать, только если оно так и задумано, бардаком.

> И при чём тут вычисления весов
apt-get install fOObAR что установит?

> и disttag?
Потому, что надо сначала восстанавливать утерянную функциональность, а не 
добавлять новые проблемы.

> Если
> будет такая проверка, то в репозитории не смогут одновременно находиться
> пакеты с именами FooBar и foobar.
Говорю ж, бардак.

> Эта проверка не про rpm и не про apt.
Если `apt-get install fOObAR` скажет "нет такого", то просто бардак, без 
весов.

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladimir D. Seleznev]

On Thu, Sep 24, 2020 at 05:44:56PM +0300, Sergey V Turchin wrote:
> On Thursday, 24 September 2020 16:57:44 MSK Vladimir D wrote:
> > On Thu, Sep 24, 2020 at 10:58:38AM +0300, Sergey V Turchin wrote:
> > > On Wednesday, 23 September 2020 18:40:39 MSK Vladimir D wrote:
> > > > On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> > > > > On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > А не лучше ли вместо этих балластных provides, как в вашем примере
> > > > > > из
> > > > > > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> > > > > > называться python3-module-normalizedname?
> > > > > 
> > > > > Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> > > > > сборочницы.
> > > > 
> > > > Почему?
> > > 
> > > чТОбы бЫло КраСиВО. Ну, И Оно Не Для Красивого Чтения, а чтобы всё было
> > > однообразно.
> > > 
> > > > Я бы лучше сделал проверку на совпадения в именах пакетов не
> > > > чувствительной к регистру.
> > > 
> > > Это больше на бардак похоже, т.к. появится ещё один вид вычисления весов
> > > пакетов. Мы ещё от disttag до конца не оправились.
> > 
> > Не бардак, а порядок.
> Бардак порядком можно назвать, только если оно так и задумано, бардаком.
> 
> > И при чём тут вычисления весов
> apt-get install fOObAR что установит?

fOObAR, если он имеется в репозитории. Ещё раз — то, что я предложил, не
относится ни к apt'у, ни к rpm, а к тому, какие пакеты могут попадать в
репозиторий.

> > и disttag?
> Потому, что надо сначала восстанавливать утерянную функциональность, а не 
> добавлять новые проблемы.
> 
> > Если
> > будет такая проверка, то в репозитории не смогут одновременно находиться
> > пакеты с именами FooBar и foobar.
> Говорю ж, бардак.

Почему бардак? Порядок же!

> > Эта проверка не про rpm и не про apt.
> Если `apt-get install fOObAR` скажет "нет такого", то просто бардак, без 
> весов.

Если такого пакета нет в репозитоии, то скажет, что нет.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Vladimir D. Seleznev писал 23.9.20 18:40:
> On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
>> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
>> 
>> [...]
>> > А не лучше ли вместо этих балластных provides, как в вашем примере из
>> > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
>> > называться python3-module-normalizedname?
>> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
>> сборочницы.
> 
> Почему? Я бы лучше сделал проверку на совпадения в именах пакетов не
> чувствительной к регистру.
Это ужасно виндовое решение, которое создаст много проблем навсегда.
Я предлагаю сделать один маленький простой шаг: если есть мнение, что 
лучше не использовать заглавные буквы, давайте примем это в полиси: 
использовать заглавные буквы в именах пакетов не рекомендуется, даже 
если где-то так назван упаковываемый проект.

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

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Igor Vlasenko писал 23.9.20 9:48:
...
> или утилиты
> perlconsole -> perl-perlconsole
> sdf -> perl-sdf
> txt2html -> perl-txt2html ?
> Это будет эстетически некрасиво.
Утилиты не должны включать в название пакета префикс языка, никому нет 
дела, на чём они написаны.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Thu, Sep 24, 2020 at 10:03:25PM +0300, Vitaly Lipatov wrote:
> Igor Vlasenko писал 23.9.20 9:48:
> ...
> > или утилиты
> > perlconsole -> perl-perlconsole
> > sdf -> perl-sdf
> > txt2html -> perl-txt2html ?
> > Это будет эстетически некрасиво.
> Утилиты не должны включать в название пакета префикс языка, никому нет дела,
> на чём они написаны.

Конечно. Это я и хотел подчеркнуть:
Provides: pythonXdist нужны.

Если вместо Provides: пытаться ввести жесткое правило именования, 
как например perl-<CPAN name>, python-<pypi name/pypi normalized name>,
то такое жесткое правило станет в итоге конфликтовать с другими,
неформальными, но действующими правилами.

Как с правилом выше.

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Igor Vlasenko писал 23.9.20 13:33:
> On Wed, Sep 23, 2020 at 01:13:05PM +0300, Dmitry V. Levin wrote:
>> 4 тысячи лишних provides - это цена, которую заплатит каждый 
>> пользователь
>> apt, причём не один раз, а при каждом использовании apt.  Для этого 
>> нужны
>> веские основания.
> 
> Гм. На фоне наших имеющихся расточительных python2/3(...) Provides,
> которых 108 тысяч 500, 4 тысячи погоды не сделают.
> Это капля в море.
Я бы также предложил компенсировать новые Provides выключением Provides 
у тех пакетов, которые не являются модулями python, но зачем-то себя 
провайдят.
Например, у меня пакет matrix-synapse:
$ epm prov matrix-synapse-1.20.1-alt1.noarch.rpm | wc -l
  $ rpm -q --provides -p matrix-synapse-1.20.1-alt1.noarch.rpm
431

Это уже 10% обсуждаемых 4 тысяч.

К сожалению, тут ещё имеется странная схема, при которой почти любой 
проект на python представлен в виде модуля, к которому в /usr/bin 
сгенерирована запускалка. Я бы очень хотел такие как бы модули видеть в 
ином каталоге, чем site-packages, но наверное это невозможно.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Anton Farygin писал 23.9.20 13:45:
...
> Ещё немного занимательной статистики:
> 
> первое поле - имя пакета, второе - provides, третье - length от версии
> этого provides в байтах. Первые 50 по уменьшению:
> 
> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",349758
> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",349706
> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",348083
Помоги понять, почему здесь есть повторы, и что такое длина от версии 
provides.
-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladislav Zavjalov]

On Thu, Sep 24, 2020 at 10:01:48PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 23.9.20 18:40:
> > On Wed, Sep 23, 2020 at 09:39:22AM +0300, Sergey V Turchin wrote:
> >> On Wednesday, 23 September 2020 09:30:40 MSK Dmitry V wrote:
> >> 
> >> [...]
> >> > А не лучше ли вместо этих балластных provides, как в вашем примере из
> >> > OpenSuSE, просто обязать все без исключения бинарные пакеты из pypi
> >> > называться python3-module-normalizedname?
> >> Я бы до кучи запретил заглавные буквы в именах любых пакетов из нашей
> >> сборочницы.
> > 
> > Почему? Я бы лучше сделал проверку на совпадения в именах пакетов не
> > чувствительной к регистру.
> Это ужасно виндовое решение, которое создаст много проблем навсегда.

Эх, я вот практически перестал пользоваться диалогами gtk/kde, после
того, как там ввели сортировку файлов, отличную от sort. Благо,
программы обычно позволяют задавать имена файлов в командной строке.
Очень печально на самом деле. Нечувствительность к регистру - одна
из проблем (вторая - числа).

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladislav Zavjalov]

On Thu, Sep 24, 2020 at 10:43:01PM +0300, Vitaly Lipatov wrote:
> Anton Farygin писал 23.9.20 13:45:
> ...
> > Ещё немного занимательной статистики:
> > 
> > первое поле - имя пакета, второе - provides, третье - length от версии
> > этого provides в байтах. Первые 50 по уменьшению:
> > 
> > "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",349758
> > "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",349706
> > "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",348083
> Помоги понять, почему здесь есть повторы, и что такое длина от версии 
> provides.

Как я понимаю, пакет предоставляет несколько библиотек (их там явно
больше трех), длина их set version provides 349758, 349706, 348083, ... байт

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton Farygin]

On 24.09.2020 22:43, Vitaly Lipatov wrote:
> Anton Farygin писал 23.9.20 13:45:
> ...
>> Ещё немного занимательной статистики:
>>
>> первое поле - имя пакета, второе - provides, третье - length от версии
>> этого provides в байтах. Первые 50 по уменьшению:
>>
>> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so",349758
>> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",349706
>> "ghc8.6.4","libHSghc-8.6.4-ghc8.6.4.so()(64bit)",348083
> Помоги понять, почему здесь есть повторы, и что такое длина от версии 
> provides.

повторы - потому что версии у этих Provides разные.

349758 - это количество байт в версии.

можно ещё вот так:

$ rpm -qp --provides ghc8.6.4-8.6.4-alt5.x86_64.rpm |wc -c
590320


$ rpm -qp --provides ghc8.6.4-8.6.4-alt5.x86_64.rpm |grep 'set:'|wc -c
588519

$ rpm -qp --provides ghc8.6.4-8.6.4-alt5.x86_64.rpm |grep -v 'set:'|wc -c
1801

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:

[...]
> > > Если
> > > будет такая проверка, то в репозитории не смогут одновременно находиться
> > > пакеты с именами FooBar и foobar.
> > Говорю ж, бардак.
> Почему бардак? Порядок же!
Бардак:
fOObaR
FoOBar
fooBAR
FOOBAr
FooBAr
fOoBAr

Порядок:
foobar

[...]

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Grigory Ustinov]

25.09.2020 8:51, Sergey V Turchin пишет:
> On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
>
> [...]
>>>> Если
>>>> будет такая проверка, то в репозитории не смогут одновременно находиться
>>>> пакеты с именами FooBar и foobar.
>>> Говорю ж, бардак.
>> Почему бардак? Порядок же!
> Бардак:
> fOObaR
> FoOBar
> fooBAR
> FOOBAr
> FooBAr
> fOoBAr
>
> Порядок:
> foobar
>
> [...]
Мне интересно, что будет в этой ситуации:

apt-cache show "python3(xattr)"

Виртуальный пакет python3(xattr) предоставляется следующими пакетами:
   python3-module-pyxattr 0.6.1-alt1:sisyphus+245000.11200.78.1@1583200202
   python3-module-xattr 0.9.7-alt1:sisyphus+245000.25500.79.1@1583242536
You should explicitly select one to show.

E: Package python3(xattr) is a virtual package with multiple providers.

ИЧСХ, у этих пакетов разные апстримы:

https://github.com/iustin/pyxattr
https://github.com/xattr/xattr

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Friday, 25 September 2020 09:18:31 MSK Grigory Ustinov wrote:

[...]
> Мне интересно, что будет в этой ситуации:
> 
> apt-cache show "python3(xattr)"
> 
> Виртуальный пакет python3(xattr) предоставляется следующими пакетами:
>    python3-module-pyxattr 0.6.1-alt1:sisyphus+245000.11200.78.1@1583200202
>    python3-module-xattr 0.9.7-alt1:sisyphus+245000.25500.79.1@1583242536
> You should explicitly select one to show.
> 
> E: Package python3(xattr) is a virtual package with multiple providers.
> 
> ИЧСХ, у этих пакетов разные апстримы:
Выживет сильнейший. ;-)
apt-get -o APT::Install::VirtualVersion=true -o APT::Install::Virtual=true 
install 'python3(xattr)'

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Friday, 25 September 2020 10:04:49 MSK Sergey V wrote:
> On Friday, 25 September 2020 09:18:31 MSK Grigory Ustinov wrote:
> 
> [...]
> 
> > Мне интересно, что будет в этой ситуации:
> > 
> > apt-cache show "python3(xattr)"
> > 
> > Виртуальный пакет python3(xattr) предоставляется следующими пакетами:
> >    python3-module-pyxattr 0.6.1-alt1:sisyphus+245000.11200.78.1@1583200202
> >    python3-module-xattr 0.9.7-alt1:sisyphus+245000.25500.79.1@1583242536
> > 
> > You should explicitly select one to show.
> > 
> > E: Package python3(xattr) is a virtual package with multiple providers.
> 
> > ИЧСХ, у этих пакетов разные апстримы:
> Выживет сильнейший. ;-)
> apt-get -o APT::Install::VirtualVersion=true -o APT::Install::Virtual=true
> install 'python3(xattr)'
При этом "сильнейший" выглядит более дохлым. Скорее всего pyxattr нужно 
удалить из репозитория.

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladimir D. Seleznev]

On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> 
> [...]
> > > > Если
> > > > будет такая проверка, то в репозитории не смогут одновременно находиться
> > > > пакеты с именами FooBar и foobar.
> > > Говорю ж, бардак.
> > Почему бардак? Порядок же!
> Бардак:
> fOObaR
> FoOBar
> fooBAR
> FOOBAr
> FooBAr
> fOoBAr

Согласен. Порядок — когда может быть одновременно только один из них, о
чём я и пытаюсь сказать.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > 
> > [...]
> > 
> > > > > Если
> > > > > будет такая проверка, то в репозитории не смогут одновременно
> > > > > находиться
> > > > > пакеты с именами FooBar и foobar.
> > > > 
> > > > Говорю ж, бардак.
> > > 
> > > Почему бардак? Порядок же!
> > 
> > Бардак:
> > fOObaR
> > FoOBar
> > fooBAR
> > FOOBAr
> > FooBAr
> > fOoBAr
> 
> Согласен. Порядок — когда может быть одновременно только один из них, о
> чём я и пытаюсь сказать.
Ааа, я наконец-то понял. Не бардак, но разброд.
С запретом заглавных букв порядка будет больше.

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Igor Vlasenko]

On Wed, Sep 23, 2020 at 09:23:34AM +0300, Igor Vlasenko wrote:
> On Wed, Sep 23, 2020 at 08:52:35AM +0300, Anton Farygin wrote:
> > Мне эта идея нравится.
> > 
> > Кто реализует ?
> 
> Я могу, после того, как закончу с perl.

В общем, сделал. Оформлено в отдельном пакете,
[#258768] DONE srpm=rpm-build-pythondist-11-alt1_11.src.rpm
собран только для python3:
rpm-build-python3dist-11-alt1_11.noarch.rpm.
python2 в сизифе пересобирать лишний раз вроде бы нет смысла,
в скором времени он может потерять большую часть модулей или вообще уйти.

Для включения в Сизифе
нужно добавить в rpm-build-python3 Requires: rpm-build-python3dist .
Для локального тестирования просто установить в chroot:
hsh-install rpm-build-python3dist.

тестировать можно на пакетах с egg-info, таких, как
python3-module-amt
есть и пакеты без egg-info, dist-info, к примеру,
python3-module-kdcproxy

-- 

I V

Re: [devel] Q: PEP-503/566 normalized names for python?

[Anton V. Boyarshinov]

В Mon, 28 Sep 2020 12:02:13 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:  
> > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > 
> > > [...]
> > >   
> > > > > > Если
> > > > > > будет такая проверка, то в репозитории не смогут одновременно
> > > > > > находиться
> > > > > > пакеты с именами FooBar и foobar.  
> > > > > 
> > > > > Говорю ж, бардак.  
> > > > 
> > > > Почему бардак? Порядок же!  
> > > 
> > > Бардак:
> > > fOObaR
> > > FoOBar
> > > fooBAR
> > > FOOBAr
> > > FooBAr
> > > fOoBAr  
> > 
> > Согласен. Порядок — когда может быть одновременно только один из них, о
> > чём я и пытаюсь сказать.  
> Ааа, я наконец-то понял. Не бардак, но разброд.
> С запретом заглавных букв порядка будет больше.
> 

И они будут назваться foobar foobar1 foobar2 и так далее...

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> В Mon, 28 Sep 2020 12:02:13 +0300
> 
> Sergey V Turchin <zerg@altlinux.org> пишет:
> > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > > Если
> > > > > > > будет такая проверка, то в репозитории не смогут одновременно
> > > > > > > находиться
> > > > > > > пакеты с именами FooBar и foobar.
> > > > > > 
> > > > > > Говорю ж, бардак.
> > > > > 
> > > > > Почему бардак? Порядок же!
> > > > 
> > > > Бардак:
> > > > fOObaR
> > > > FoOBar
> > > > fooBAR
> > > > FOOBAr
> > > > FooBAr
> > > > fOoBAr
> > > 
> > > Согласен. Порядок — когда может быть одновременно только один из них, о
> > > чём я и пытаюсь сказать.
> > 
> > Ааа, я наконец-то понял. Не бардак, но разброд.
> > С запретом заглавных букв порядка будет больше.
> 
> И они будут назваться foobar foobar1 foobar2 и так далее...
Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Andrey Savchenko]

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

On Mon, 28 Sep 2020 16:00:25 +0300 Sergey V Turchin wrote:
> On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> > В Mon, 28 Sep 2020 12:02:13 +0300
> > 
> > Sergey V Turchin <zerg@altlinux.org> пишет:
> > > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > > Если
> > > > > > > > будет такая проверка, то в репозитории не смогут одновременно
> > > > > > > > находиться
> > > > > > > > пакеты с именами FooBar и foobar.
> > > > > > > 
> > > > > > > Говорю ж, бардак.
> > > > > > 
> > > > > > Почему бардак? Порядок же!
> > > > > 
> > > > > Бардак:
> > > > > fOObaR
> > > > > FoOBar
> > > > > fooBAR
> > > > > FOOBAr
> > > > > FooBAr
> > > > > fOoBAr
> > > > 
> > > > Согласен. Порядок — когда может быть одновременно только один из них, о
> > > > чём я и пытаюсь сказать.
> > > 
> > > Ааа, я наконец-то понял. Не бардак, но разброд.
> > > С запретом заглавных букв порядка будет больше.
> > 
> > И они будут назваться foobar foobar1 foobar2 и так далее...
> Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?

Да хоть L1br30FF1c3. Какая разница, если пакет работает и по
apt-cache ищется.

Разрешить заглавные стоит хотя бы потому, что апстримы называют
свои пакеты порой с заглавными. И у пользователей будет меньше
путаницы, если мы будет называть так же, как апстрим (по крайней
мере там, где это не пересекается со схемами наименований
модулей perl/python и т.п.).

Best regards,
Andrew Savchenko

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

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Monday, 28 September 2020 16:15:44 MSK Andrey Savchenko wrote:
> On Mon, 28 Sep 2020 16:00:25 +0300 Sergey V Turchin wrote:
> 
> > On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> > 
> > > В Mon, 28 Sep 2020 12:02:13 +0300
> > > 
> > > Sergey V Turchin <zerg@altlinux.org> пишет:
> > > 
> > > > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > > 
> > > > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > > 
> > > > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > > > > Если
> > > > > > > > > будет такая проверка, то в репозитории не смогут
> > > > > > > > > одновременно
> > > > > > > > > находиться
> > > > > > > > > пакеты с именами FooBar и foobar.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Говорю ж, бардак.
> > > > > > > 
> > > > > > > 
> > > > > > > Почему бардак? Порядок же!
> > > > > > 
> > > > > > 
> > > > > > Бардак:
> > > > > > fOObaR
> > > > > > FoOBar
> > > > > > fooBAR
> > > > > > FOOBAr
> > > > > > FooBAr
> > > > > > fOoBAr
> > > > > 
> > > > > 
> > > > > Согласен. Порядок — когда может быть одновременно только один из
> > > > > них, о
> > > > > чём я и пытаюсь сказать.
> > > > 
> > > > 
> > > > Ааа, я наконец-то понял. Не бардак, но разброд.
> > > > С запретом заглавных букв порядка будет больше.
> > > 
> > > 
> > > И они будут назваться foobar foobar1 foobar2 и так далее...
> > 
> > Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?
> 
> 
> Да хоть L1br30FF1c3.
Больше путаницы. ;-)

> Какая разница, если пакет работает и по
> apt-cache ищется.
Принципиальная. Человек пользующийся Synaptic не осилит этот случай.

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

> И у пользователей будет меньше путаницы,
Да, я и предрагаю "меньше путаницы". Вы разве не заметили? ;-)

> если мы будет называть так же, как апстрим
Ага. Потом и юникодные имена подтянутся. ;-)

> (по крайней
> мере там, где это не пересекается со схемами наименований
> модулей perl/python и т.п.).
В описаних пакетов они так и называются родными именами.

-- 
Regards, Sergey.

Re: [devel] [JT] Q: PEP-503/566 normalized names for python?

[Oleg Solovyov]

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

On понедельник, 28 сентября 2020 г. 17:54:48 MSK Sergey V Turchin wrote:
> Ага. Потом и юникодные имена подтянутся. ;-)
*передаёт привет тайпсквоттингу*

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vladimir D. Seleznev]

On Mon, Sep 28, 2020 at 04:00:25PM +0300, Sergey V Turchin wrote:
> On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> > В Mon, 28 Sep 2020 12:02:13 +0300
> > 
> > Sergey V Turchin <zerg@altlinux.org> пишет:
> > > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > > Если
> > > > > > > > будет такая проверка, то в репозитории не смогут одновременно
> > > > > > > > находиться
> > > > > > > > пакеты с именами FooBar и foobar.
> > > > > > > 
> > > > > > > Говорю ж, бардак.
> > > > > > 
> > > > > > Почему бардак? Порядок же!
> > > > > 
> > > > > Бардак:
> > > > > fOObaR
> > > > > FoOBar
> > > > > fooBAR
> > > > > FOOBAr
> > > > > FooBAr
> > > > > fOoBAr
> > > > 
> > > > Согласен. Порядок — когда может быть одновременно только один из них, о
> > > > чём я и пытаюсь сказать.
> > > 
> > > Ааа, я наконец-то понял. Не бардак, но разброд.
> > > С запретом заглавных букв порядка будет больше.
> > 
> > И они будут назваться foobar foobar1 foobar2 и так далее...
> Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?

Лучше LibreOffice. libreoffice как раз-таки создаст путаницу: на глаз
это похоже на название какой-то библиотеки.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Monday, 28 September 2020 21:09:37 MSK Vladimir D wrote:
> On Mon, Sep 28, 2020 at 04:00:25PM +0300, Sergey V Turchin wrote:
> > On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> > > В Mon, 28 Sep 2020 12:02:13 +0300
> > > 
> > > Sergey V Turchin <zerg@altlinux.org> пишет:
> > > > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > > > Если
> > > > > > > > > будет такая проверка, то в репозитории не смогут
> > > > > > > > > одновременно
> > > > > > > > > находиться
> > > > > > > > > пакеты с именами FooBar и foobar.
> > > > > > > > 
> > > > > > > > Говорю ж, бардак.
> > > > > > > 
> > > > > > > Почему бардак? Порядок же!
> > > > > > 
> > > > > > Бардак:
> > > > > > fOObaR
> > > > > > FoOBar
> > > > > > fooBAR
> > > > > > FOOBAr
> > > > > > FooBAr
> > > > > > fOoBAr
> > > > > 
> > > > > Согласен. Порядок — когда может быть одновременно только один из
> > > > > них, о
> > > > > чём я и пытаюсь сказать.
> > > > 
> > > > Ааа, я наконец-то понял. Не бардак, но разброд.
> > > > С запретом заглавных букв порядка будет больше.
> > > 
> > > И они будут назваться foobar foobar1 foobar2 и так далее...
> > 
> > Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?
> 
> Лучше LibreOffice. libreoffice как раз-таки создаст путаницу: на глаз
> это похоже на название какой-то библиотеки.
Специально же намекнул на libre-office. ;-[

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Ivan A. Melnikov]

On Tue, Sep 29, 2020 at 10:26:34AM +0300, Sergey V Turchin wrote:
> On Monday, 28 September 2020 21:09:37 MSK Vladimir D wrote:
> > On Mon, Sep 28, 2020 at 04:00:25PM +0300, Sergey V Turchin wrote:
> > > On Monday, 28 September 2020 15:28:18 MSK Anton V wrote:
> > > > В Mon, 28 Sep 2020 12:02:13 +0300
> > > > 
> > > > Sergey V Turchin <zerg@altlinux.org> пишет:
> > > > > On Saturday, 26 September 2020 03:23:29 MSK Vladimir D wrote:
> > > > > > On Fri, Sep 25, 2020 at 08:51:25AM +0300, Sergey V Turchin wrote:
> > > > > > > On Thursday, 24 September 2020 19:15:04 MSK Vladimir D wrote:
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > > > Если
> > > > > > > > > > будет такая проверка, то в репозитории не смогут
> > > > > > > > > > одновременно
> > > > > > > > > > находиться
> > > > > > > > > > пакеты с именами FooBar и foobar.
> > > > > > > > > 
> > > > > > > > > Говорю ж, бардак.
> > > > > > > > 
> > > > > > > > Почему бардак? Порядок же!
> > > > > > > 
> > > > > > > Бардак:
> > > > > > > fOObaR
> > > > > > > FoOBar
> > > > > > > fooBAR
> > > > > > > FOOBAr
> > > > > > > FooBAr
> > > > > > > fOoBAr
> > > > > > 
> > > > > > Согласен. Порядок — когда может быть одновременно только один из
> > > > > > них, о
> > > > > > чём я и пытаюсь сказать.
> > > > > 
> > > > > Ааа, я наконец-то понял. Не бардак, но разброд.
> > > > > С запретом заглавных букв порядка будет больше.
> > > > 
> > > > И они будут назваться foobar foobar1 foobar2 и так далее...
> > > 
> > > Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?
> > 
> > Лучше LibreOffice. libreoffice как раз-таки создаст путаницу: на глаз
> > это похоже на название какой-то библиотеки.
> Специально же намекнул на libre-office. ;-[

Похоже на подпакет к libre ;D

-- 
  wbr,
    iv m.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Sergey V Turchin]

On Tuesday, 29 September 2020 11:01:35 MSK Ivan A wrote:

[...]
> > > > Достаточно foobar по очереди менять с foo-bar. Или лучше LiBrEOFfIcE?
> > > 
> > > Лучше LibreOffice. libreoffice как раз-таки создаст путаницу: на глаз
> > > это похоже на название какой-то библиотеки.
> > 
> > Специально же намекнул на libre-office. ;-[
> 
> Похоже на подпакет к libre ;D
Немного да, но не страшно.
Живут и не жужжат и с https://launchpad.net/ubuntu/+source/libreoffice .

-- 
Regards, Sergey.

Re: [devel] Q: PEP-503/566 normalized names for python?

[Vitaly Lipatov]

Igor Vlasenko писал 28.9.20 13:00:
> On Wed, Sep 23, 2020 at 09:23:34AM +0300, Igor Vlasenko wrote:
>> On Wed, Sep 23, 2020 at 08:52:35AM +0300, Anton Farygin wrote:
>> > Мне эта идея нравится.
>> >
>> > Кто реализует ?
>> 
>> Я могу, после того, как закончу с perl.
> 
> В общем, сделал. Оформлено в отдельном пакете,
> [#258768] DONE srpm=rpm-build-pythondist-11-alt1_11.src.rpm
> собран только для python3:
> rpm-build-python3dist-11-alt1_11.noarch.rpm.
> python2 в сизифе пересобирать лишний раз вроде бы нет смысла,
> в скором времени он может потерять большую часть модулей или вообще 
> уйти.
> 
> Для включения в Сизифе
> нужно добавить в rpm-build-python3 Requires: rpm-build-python3dist .
> Для локального тестирования просто установить в chroot:
> hsh-install rpm-build-python3dist.
> 
> тестировать можно на пакетах с egg-info, таких, как
> python3-module-amt
> есть и пакеты без egg-info, dist-info, к примеру,
> python3-module-kdcproxy

Просьба как-то сдвинуть решение
https://bugzilla.altlinux.org/show_bug.cgi?id=39003

-- 
С уважением,
Виталий Липатов,
ALT Linux Team