[devel] Зависимости ruby-libs и libruby

[devel] Зависимости ruby-libs и libruby

[Anton Farygin]

Всем привет.

Это почти пустая система, на которой был установлен libruby и ruby-libs:

# apt-get dist-upgrade
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Подсчет обновлений... Завершено
Следующие пакеты будут ОБНОВЛЕНЫ:
   libruby ruby-stdlibs
Следующие НОВЫЕ пакеты будут установлены:
   bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri 
ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc 
ruby-rubygems-update
   ruby-test-unit ruby-xmlrpc
2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не 
будет обновлено.
Необходимо получить 0B/4555kB архивов.
После распаковки потребуется дополнительно 2941kB дискового пространства.


Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты 
ruby не требовались для ruby-stdlibs.

Re: [devel] Зависимости ruby-libs и libruby

[Dmitry V. Levin]

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

On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
> Всем привет.
> 
> Это почти пустая система, на которой был установлен libruby и ruby-libs:
> 
> # apt-get dist-upgrade
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Подсчет обновлений... Завершено
> Следующие пакеты будут ОБНОВЛЕНЫ:
>    libruby ruby-stdlibs
> Следующие НОВЫЕ пакеты будут установлены:
>    bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri 
> ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc 
> ruby-rubygems-update
>    ruby-test-unit ruby-xmlrpc
> 2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не 
> будет обновлено.
> Необходимо получить 0B/4555kB архивов.
> После распаковки потребуется дополнительно 2941kB дискового пространства.
> 
> Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты 
> ruby не требовались для ruby-stdlibs.

И почему все эти пакеты так странно названы?
Им ведь всем полагается иметь префикс ruby-.

Какой-то откровенный бардак теперь с этим ruby.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

20.01.2019, 10:58, "Anton Farygin" <rider@basealt.ru>:
> Всем привет.
>
> Это почти пустая система, на которой был установлен libruby и ruby-libs:
>
> # apt-get dist-upgrade
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Подсчет обновлений... Завершено
> Следующие пакеты будут ОБНОВЛЕНЫ:
>    libruby ruby-stdlibs
> Следующие НОВЫЕ пакеты будут установлены:
>    bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
> ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
> ruby-rubygems-update
>    ruby-test-unit ruby-xmlrpc
> 2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
> будет обновлено.
> Необходимо получить 0B/4555kB архивов.
> После распаковки потребуется дополнительно 2941kB дискового пространства.
>
> Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
> ruby не требовались для ruby-stdlibs.

Раньше они были впилены как необновляемые гемы прямо внутри руби srpm.

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

-- 
С уважением,
 Скрылевъ Малъ
+79055245451

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

20.01.2019, 15:31, "Dmitry V. Levin" <ldv@altlinux.org>:
> On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
>>  Всем привет.
>>
>>  Это почти пустая система, на которой был установлен libruby и ruby-libs:
>>
>>  # apt-get dist-upgrade
>>  Чтение списков пакетов... Завершено
>>  Построение дерева зависимостей... Завершено
>>  Подсчет обновлений... Завершено
>>  Следующие пакеты будут ОБНОВЛЕНЫ:
>>     libruby ruby-stdlibs
>>  Следующие НОВЫЕ пакеты будут установлены:
>>     bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
>>  ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
>>  ruby-rubygems-update
>>     ruby-test-unit ruby-xmlrpc
>>  2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
>>  будет обновлено.
>>  Необходимо получить 0B/4555kB архивов.
>>  После распаковки потребуется дополнительно 2941kB дискового пространства.
>>
>>  Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
>>  ruby не требовались для ruby-stdlibs.
>
> И почему все эти пакеты так странно названы?
> Им ведь всем полагается иметь префикс ruby-.

Да видимо так по документам, но бывает ошибаешься с названием.

>
> Какой-то откровенный бардак теперь с этим ruby.

Хорошо бы конечно привести названия в более понятный рубишникам вид.

>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
С уважением,
 Скрылевъ Малъ
+79055245451

Re: [devel] Зависимости ruby-libs и libruby

[Vladimir D. Seleznev]

On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
> 
> 
> 20.01.2019, 15:31, "Dmitry V. Levin" <ldv@altlinux.org>:
> > On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
> >>  Всем привет.
> >>
> >>  Это почти пустая система, на которой был установлен libruby и ruby-libs:
> >>
> >>  # apt-get dist-upgrade
> >>  Чтение списков пакетов... Завершено
> >>  Построение дерева зависимостей... Завершено
> >>  Подсчет обновлений... Завершено
> >>  Следующие пакеты будут ОБНОВЛЕНЫ:
> >>     libruby ruby-stdlibs
> >>  Следующие НОВЫЕ пакеты будут установлены:
> >>     bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
> >>  ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
> >>  ruby-rubygems-update
> >>     ruby-test-unit ruby-xmlrpc
> >>  2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
> >>  будет обновлено.
> >>  Необходимо получить 0B/4555kB архивов.
> >>  После распаковки потребуется дополнительно 2941kB дискового пространства.
> >>
> >>  Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
> >>  ruby не требовались для ruby-stdlibs.
> >
> > И почему все эти пакеты так странно названы?
> > Им ведь всем полагается иметь префикс ruby-.
> 
> Да видимо так по документам, но бывает ошибаешься с названием.
> 
> >
> > Какой-то откровенный бардак теперь с этим ruby.
> 
> Хорошо бы конечно привести названия в более понятный рубишникам вид.

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

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby

[Michael Shigorin]

On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
> > Какой-то откровенный бардак теперь с этим ruby.
> Хорошо бы конечно привести названия в более понятный рубишникам вид.

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Зависимости ruby-libs и libruby

[Anton Farygin]

25.01.2019 19:43, Michael Shigorin пишет:
> On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
>>> Какой-то откровенный бардак теперь с этим ruby.
>> Хорошо бы конечно привести названия в более понятный рубишникам вид.
> Такие изменения в любом случае проводить анонсированно стоит,
> а не явочным порядком.
>
Вообще то я всё-таки не об этом.

У меня раньше был установлен ruby-stdlibs а тут появился gem, irb, erb и 
собственно сам ruby.

если gem, irb, erb и ruby жили в пакете ruby-stdlibs, то вопросов нет. А 
если не так - то лучше конечно сделать упаковку ruby таким образом, что 
установка пакета ruby-stdlibs, нужная только для libruby и тем, кто с 
ним слинкован - не требовал больше ничего дополнительного типа gem.


Но да, конечно было бы удобно паковать пакеты ruby как ruby-что-то-там. 
Но вообще не обязательно. Если апстримный пакет называется irb, а не 
ruby/irb, то наверное всё-таки не совсем правильно его называть 
ruby-irb, хотя как по мне - было бы удобно.

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

25.01.2019, 19:39, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
>>  20.01.2019, 15:31, "Dmitry V. Levin" <ldv@altlinux.org>:
>>  > On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
>>  >>  Всем привет.
>>  >>
>>  >>  Это почти пустая система, на которой был установлен libruby и ruby-libs:
>>  >>
>>  >>  # apt-get dist-upgrade
>>  >>  Чтение списков пакетов... Завершено
>>  >>  Построение дерева зависимостей... Завершено
>>  >>  Подсчет обновлений... Завершено
>>  >>  Следующие пакеты будут ОБНОВЛЕНЫ:
>>  >>     libruby ruby-stdlibs
>>  >>  Следующие НОВЫЕ пакеты будут установлены:
>>  >>     bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
>>  >>  ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
>>  >>  ruby-rubygems-update
>>  >>     ruby-test-unit ruby-xmlrpc
>>  >>  2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
>>  >>  будет обновлено.
>>  >>  Необходимо получить 0B/4555kB архивов.
>>  >>  После распаковки потребуется дополнительно 2941kB дискового пространства.
>>  >>
>>  >>  Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
>>  >>  ruby не требовались для ruby-stdlibs.
>>  >
>>  > И почему все эти пакеты так странно названы?
>>  > Им ведь всем полагается иметь префикс ruby-.
>>
>>  Да видимо так по документам, но бывает ошибаешься с названием.
>>
>>  >
>>  > Какой-то откровенный бардак теперь с этим ruby.
>>
>>  Хорошо бы конечно привести названия в более понятный рубишникам вид.
>
> По-моему, более понятный рубишникам и нерубишникам вид названия пакетов
> с префиксом ruby-. Пожалуйста, именуйте пакеты, в которых упакованы
> модули ruby, с этим префиксом.

Для рубишников например есть 3 вида руби наборов, это гемы, это скрипты (или модули) и это веб-приложения скажем на рельсах или синатре.

Соответстенно когда разрабатывалась нонешняя "полиция" для руби, был по большому счеты только 1 вид, это сторонние модули (которые почти всегда имели префикс ruby- а иногда суффикс или вообще ничего), со введением невадно модели представления гемов, а также доабвления веб-приложений например пупета или форемана, появились еще два, в модули раскладывается ruby-stdlibs, все модули стали оформлены как гемы (и соответственно почти все они попали в другие папки), а приложения на рельсах вообще имею свою собственную структуру.

Так вот для рубишинка префикс ruby- совсем не ясен, что именно он представляет.

Я бы разобрал так:

1. гемы имеют префик gem-
2. приложения на рельсах/синатре либо соответствующий префикс, либо rubyapp-
3. модули по старинке ruby-

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Vladimir D. Seleznev]

On Sat, Jan 26, 2019 at 07:08:08PM +0300, Скрылевъ Малъ wrote:
> > По-моему, более понятный рубишникам и нерубишникам вид названия пакетов
> > с префиксом ruby-. Пожалуйста, именуйте пакеты, в которых упакованы
> > модули ruby, с этим префиксом.
> 
> Для рубишников например есть 3 вида руби наборов, это гемы, это
> скрипты (или модули) и это веб-приложения скажем на рельсах или
> синатре.
> 
> Соответстенно когда разрабатывалась нонешняя "полиция" для руби, был
> по большому счеты только 1 вид, это сторонние модули (которые почти
> всегда имели префикс ruby- а иногда суффикс или вообще ничего), со
> введением невадно модели представления гемов, а также доабвления
> веб-приложений например пупета или форемана, появились еще два, в
> модули раскладывается ruby-stdlibs, все модули стали оформлены как
> гемы (и соответственно почти все они попали в другие папки), а
> приложения на рельсах вообще имею свою собственную структуру.
> 
> Так вот для рубишинка префикс ruby- совсем не ясен, что именно он
> представляет.
> 
> Я бы разобрал так:
> 
> 1. гемы имеют префик gem-

Насколько я знаю, RubyGems — это один из способов дистрибуции модулей
руби. Не очевидно, чем это не модули руби.

> 2. приложения на рельсах/синатре либо соответствующий префикс, либо rubyapp-

Пакетам приложений, написанных на руби, конечно же, не нужно именовать с
префиксом ruby-.

> 3. модули по старинке ruby-

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby

[Vitaly Chikunov]

On Sat, Jan 26, 2019 at 07:08:08PM +0300, Скрылевъ Малъ wrote:
> 
> 
> 25.01.2019, 19:39, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> > On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
> >>  20.01.2019, 15:31, "Dmitry V. Levin" <ldv@altlinux.org>:
> >>  > On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
> >>  >>  Всем привет.
> >>  >>
> >>  >>  Это почти пустая система, на которой был установлен libruby и ruby-libs:
> >>  >>
> >>  >>  # apt-get dist-upgrade
> >>  >>  Чтение списков пакетов... Завершено
> >>  >>  Построение дерева зависимостей... Завершено
> >>  >>  Подсчет обновлений... Завершено
> >>  >>  Следующие пакеты будут ОБНОВЛЕНЫ:
> >>  >>     libruby ruby-stdlibs
> >>  >>  Следующие НОВЫЕ пакеты будут установлены:
> >>  >>     bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
> >>  >>  ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
> >>  >>  ruby-rubygems-update
> >>  >>     ruby-test-unit ruby-xmlrpc
> >>  >>  2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
> >>  >>  будет обновлено.
> >>  >>  Необходимо получить 0B/4555kB архивов.
> >>  >>  После распаковки потребуется дополнительно 2941kB дискового пространства.
> >>  >>
> >>  >>  Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
> >>  >>  ruby не требовались для ruby-stdlibs.
> >>  >
> >>  > И почему все эти пакеты так странно названы?
> >>  > Им ведь всем полагается иметь префикс ruby-.
> >>
> >>  Да видимо так по документам, но бывает ошибаешься с названием.
> >>
> >>  >
> >>  > Какой-то откровенный бардак теперь с этим ruby.
> >>
> >>  Хорошо бы конечно привести названия в более понятный рубишникам вид.
> >
> > По-моему, более понятный рубишникам и нерубишникам вид названия пакетов
> > с префиксом ruby-. Пожалуйста, именуйте пакеты, в которых упакованы
> > модули ruby, с этим префиксом.
> 
> Для рубишников например есть 3 вида руби наборов, это гемы, это скрипты (или модули) и это веб-приложения скажем на рельсах или синатре.

Есть приложения на руби - это скрипты, есть библиотеки к руби скриптам -
это гемы (или модули). Скрипты, это не противоположность гемов и не синоним
модулей. Что такое "руби наборы" я нагуглить не смог.

Gem это способ инсталла ruby приложения или модуля, то есть package manager.
Это все равно что писать префикс apt- для пакета, который есть в дебиане.

Кроме того, пользователю репозитория понятно, если то, что он искал
нашлось с ruby- то это что-то для языка руби. Если там будет написано
gem или еще какое-то модное слово, то он может не понять, что это то
же что и ruby. И он не обязан знать какие сейчас пакетные менеджеры
популярны в каком языке.

> 
> Соответстенно когда разрабатывалась нонешняя "полиция" для руби, был по большому счеты только 1 вид, это сторонние модули (которые почти всегда имели префикс ruby- а иногда суффикс или вообще ничего), со введением невадно модели представления гемов, а также доабвления веб-приложений например пупета или форемана, появились еще два, в модули раскладывается ruby-stdlibs, все модули стали оформлены как гемы (и соответственно почти все они попали в другие папки), а приложения на рельсах вообще имею свою собственную структуру.

Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
Например, модуль для руби скорее всего относится к руби, а не к гему.
Модуль для rails к rails, а не к gem или rubyapps.

> 
> Так вот для рубишинка префикс ruby- совсем не ясен, что именно он представляет.
> 
> Я бы разобрал так:
> 
> 1. гемы имеют префик gem-
> 2. приложения на рельсах/синатре либо соответствующий префикс, либо rubyapp-
> 3. модули по старинке ruby-

Гемы и "модули по старинке" не одним и тем-же require подцепляются?
Следовательно, нет никакой разницы "что именно они представляют" и
в какие папки попадает.

> 
> -- 
> 
> Малъ Скрылевъ
> about.me/majioa
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Зависимости ruby-libs и libruby

[Anton Farygin]

26.01.2019 11:38, Andrey Cherepanov пишет:
> 26.01.2019 00:20, Anton Farygin пишет:
>> 25.01.2019 19:43, Michael Shigorin пишет:
>>> On Sun, Jan 20, 2019 at 10:09:52PM +0300, Скрылевъ Малъ wrote:
>>>>> Какой-то откровенный бардак теперь с этим ruby.
>>>> Хорошо бы конечно привести названия в более понятный рубишникам вид.
>>> Такие изменения в любом случае проводить анонсированно стоит,
>>> а не явочным порядком.
>>>
>> Вообще то я всё-таки не об этом.
>>
>> У меня раньше был установлен ruby-stdlibs а тут появился gem, irb, 
>> erb и собственно сам ruby.
>>
>> если gem, irb, erb и ruby жили в пакете ruby-stdlibs, то вопросов 
>> нет. А если не так - то лучше конечно сделать упаковку ruby таким 
>> образом, что установка пакета ruby-stdlibs, нужная только для libruby 
>> и тем, кто с ним слинкован - не требовал больше ничего 
>> дополнительного типа gem.
>>
>>
>> Но да, конечно было бы удобно паковать пакеты ruby как 
>> ruby-что-то-там. Но вообще не обязательно. Если апстримный пакет 
>> называется irb, а не ruby/irb, то наверное всё-таки не совсем 
>> правильно его называть ruby-irb, хотя как по мне - было бы удобно. 
> gem, erb и прочие пакеты не были в ruby-stdlibs. Они были в 
> ruby-tools, который распилили на отдельные пакеты.

ruby-tools ранее не был установлен на той системе, на которую они 
влетели уже в распиленном состоянии.

Т.е. - сейчас вот это примерно выглядит так:

# apt-get remove gem
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
   bundle erb gem gem-did-you-mean gem-power-assert irb kde5 
kde5-dolphin kde5-mini kde5-small rake rdoc ri ruby ruby-bundler 
ruby-minitest ruby-net-telnet
   ruby-rake ruby-rdoc ruby-rubygems-update ruby-stdlibs ruby-test-unit 
ruby-xmlrpc
0 будет обновлено, 0 новых установлено, 23 пакетов будет удалено и 0 не 
будет обновлено.
Необходимо получить 0B архивов.
После распаковки будет освобождено 17,2MB дискового пространства.

>
> По полиси:
> /Вышесказанное относится к pure-module пакетам, а не end-user 
> программам, написанным на языке ruby (например, alexandria). В этом 
> случае имя и группа пакета должны соответствовать действительности.
> /То есть если пакет содержит исполняемый файл с именем, то по полиси 
> префикс ruby- необязателен,
Да, согласен.

Re: [devel] Зависимости ruby-libs и libruby

[Alexey Shabalin]

вс, 20 янв. 2019 г. в 15:31, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
> > Всем привет.
> >
> > Это почти пустая система, на которой был установлен libruby и ruby-libs:
> >
> > # apt-get dist-upgrade
> > Чтение списков пакетов... Завершено
> > Построение дерева зависимостей... Завершено
> > Подсчет обновлений... Завершено
> > Следующие пакеты будут ОБНОВЛЕНЫ:
> >    libruby ruby-stdlibs
> > Следующие НОВЫЕ пакеты будут установлены:
> >    bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
> > ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
> > ruby-rubygems-update
> >    ruby-test-unit ruby-xmlrpc
> > 2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
> > будет обновлено.
> > Необходимо получить 0B/4555kB архивов.
> > После распаковки потребуется дополнительно 2941kB дискового пространства.
> >
> > Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
> > ruby не требовались для ruby-stdlibs.
>
> И почему все эти пакеты так странно названы?
> Им ведь всем полагается иметь префикс ruby-.
>
> Какой-то откровенный бардак теперь с этим ruby.

А можно вернуть назад автопоиск Provides и Requires в ruby.
Мне всегда нравился ALT тем, что нужно минимум прописывать в Requires,
потому что для всех языков очень хорошо работал автопоск.
В ruby теперь нет никакого автопоска зависимостей.
И меня напрягает указывать 100500 пакетов в Requires:
gemspec хорошо может быть, черт его знает, кому он нужен(их пишут люди
с ошибками),
но мне на них наплевать, если в /usr/bin лежит скрипт на ruby и для
него никто не выставляет зависимости на модули ruby.
Я не против добавления нового функционала (gemspec), но нельзя ли
сохранить и старый?

-- 
Alexey Shabalin

Re: [devel] Зависимости ruby-libs и libruby

[Alexey Shabalin]

пн, 28 янв. 2019 г. в 21:48, Alexey Shabalin <a.shabalin@gmail.com>:
>
> вс, 20 янв. 2019 г. в 15:31, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Sun, Jan 20, 2019 at 10:58:37AM +0300, Anton Farygin wrote:
> > > Всем привет.
> > >
> > > Это почти пустая система, на которой был установлен libruby и ruby-libs:
> > >
> > > # apt-get dist-upgrade
> > > Чтение списков пакетов... Завершено
> > > Построение дерева зависимостей... Завершено
> > > Подсчет обновлений... Завершено
> > > Следующие пакеты будут ОБНОВЛЕНЫ:
> > >    libruby ruby-stdlibs
> > > Следующие НОВЫЕ пакеты будут установлены:
> > >    bundle erb gem gem-did-you-mean gem-power-assert irb rake rdoc ri
> > > ruby ruby-bundler ruby-minitest ruby-net-telnet ruby-rake ruby-rdoc
> > > ruby-rubygems-update
> > >    ruby-test-unit ruby-xmlrpc
> > > 2 будет обновлено, 18 новых установлено, 0 пакетов будет удалено и 0 не
> > > будет обновлено.
> > > Необходимо получить 0B/4555kB архивов.
> > > После распаковки потребуется дополнительно 2941kB дискового пространства.
> > >
> > > Не знаю, ошибка это или нет, но раньше rake rdoc и другие инструменты
> > > ruby не требовались для ruby-stdlibs.
> >
> > И почему все эти пакеты так странно названы?
> > Им ведь всем полагается иметь префикс ruby-.
> >
> > Какой-то откровенный бардак теперь с этим ruby.
>
> А можно вернуть назад автопоиск Provides и Requires в ruby.
> Мне всегда нравился ALT тем, что нужно минимум прописывать в Requires,
> потому что для всех языков очень хорошо работал автопоск.
> В ruby теперь нет никакого автопоска зависимостей.
> И меня напрягает указывать 100500 пакетов в Requires:
> gemspec хорошо может быть, черт его знает, кому он нужен(их пишут люди
> с ошибками),
> но мне на них наплевать, если в /usr/bin лежит скрипт на ruby и для
> него никто не выставляет зависимости на модули ruby.
> Я не против добавления нового функционала (gemspec), но нельзя ли
> сохранить и старый?

Что бы не быть голословным. Пример.
Пакет opennebula-server. Это не модуль на ruby, никаких gemspec. Это приложение.
Вот зависимости в пакете из p8:
ruby(aws-sdk)
ruby(azure)
ruby(cgi)
ruby(getoptlong)
ruby(mysql2)
ruby(open3)
ruby(optparse/time)
ruby(pathname)
ruby(resolv)
ruby(sequel)
ruby(shellwords)
ruby(sqlite3)
ruby(timeout)
ruby(zlib)

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

-- 
Alexey Shabalin

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

27.01.2019, 03:17, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Sat, Jan 26, 2019 at 07:08:08PM +0300, Скрылевъ Малъ wrote:
>>  > По-моему, более понятный рубишникам и нерубишникам вид названия пакетов
>>  > с префиксом ruby-. Пожалуйста, именуйте пакеты, в которых упакованы
>>  > модули ruby, с этим префиксом.
>>
>>  Для рубишников например есть 3 вида руби наборов, это гемы, это
>>  скрипты (или модули) и это веб-приложения скажем на рельсах или
>>  синатре.
>>
>>  Соответстенно когда разрабатывалась нонешняя "полиция" для руби, был
>>  по большому счеты только 1 вид, это сторонние модули (которые почти
>>  всегда имели префикс ruby- а иногда суффикс или вообще ничего), со
>>  введением невадно модели представления гемов, а также доабвления
>>  веб-приложений например пупета или форемана, появились еще два, в
>>  модули раскладывается ruby-stdlibs, все модули стали оформлены как
>>  гемы (и соответственно почти все они попали в другие папки), а
>>  приложения на рельсах вообще имею свою собственную структуру.
>>
>>  Так вот для рубишинка префикс ruby- совсем не ясен, что именно он
>>  представляет.
>>
>>  Я бы разобрал так:
>>
>>  1. гемы имеют префик gem-
>
> Насколько я знаю, RubyGems — это один из способов дистрибуции модулей
> руби. Не очевидно, чем это не модули руби.
>

Сейчас единственный для широкого круга модулей, но да руби-модуль, однако например ruby-stdlibs также поставляет некоторые модули, но в другом формате, какие либо пакеты также хотящие себя установить не в структуру папок site_ruby(как ruby-stdlibs), а в структуру gems, будут иметь иное расположение в дереве руби, а также вылядеть будут по иному для рубишной подсистемы. Потому и отличаться должны, как минимум для нас, чтобы избежать путаницы в терминологии.



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

> Гемы и "модули по старинке" не одним и тем-же require подцепляются?
> Следовательно, нет никакой разницы "что именно они представляют" и
> в какие папки попадает.

Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

> А можно вернуть назад автопоиск Provides и Requires в ruby.

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

> Мне всегда нравился ALT тем, что нужно минимум прописывать в Requires,
> потому что для всех языков очень хорошо работал автопоск.
> В ruby теперь нет никакого автопоска зависимостей.
Есть он просто по другому работает.

> И меня напрягает указывать 100500 пакетов в Requires:
> gemspec хорошо может быть, черт его знает, кому он нужен(их пишут люди
> с ошибками),
rubygems сервер  не пропустит пакеты с неправильными зависимостями, если зависимости какие-либо не указаны, то в Gemfile, то приложение у разработчика просто не будет работать, даже в режиме разработки. Так что все зависимости прописаные будь-то в .gemspec или Gemfile, подцепятся автоматом, при правильном вызове макросов настройки руби подсистемы, смотри напр. пакет рельс.

> но мне на них наплевать, если в /usr/bin лежит скрипт на ruby и для
> него никто не выставляет зависимости на модули ruby.
Сейчас пока да, это единственное место, где не определяется зависимость скрипта от его модуля, и приходится править руками, но это ожидается быть исправленным в ближайшее время.

> Я не против добавления нового функционала (gemspec), но нельзя ли
> сохранить и старый?

Нет, они будут конфликтовать.

> --
> Alexey Shabalin
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Ivan A. Melnikov]

On Mon, Jan 28, 2019 at 10:44:17PM +0300, Andrey Cherepanov wrote:
> 
> 
> 28 января 2019 г. 22:30:51 GMT+03:00, Aleksey Novodvorsky <aen@altlinux.ru> пишет:
> >понедельник, 28 января 2019 г. пользователь Andrey Cherepanov <
> >cas@altlinux.org> написал:
> >
> >> 28 января 2019 г. 22:06:03 GMT+03:00, Alexey Shabalin <
> >> a.shabalin@gmail.com> пишет:
[...]
> >>> А в пакете из сизифа пусто, как будто ничего не требуется.
> >>> У меня совсем нет желания выяснять вручную имена пакетов.
> >>>
> >> Побудь добрым врачом, лечащим безбашенный апстрим. Тем более в
> >> единичном экземпляре.
> >>
> > Кто сломал, тот и лечит.
> >
>
> С точки зрения инфраструктуры Ruby это как раз исправление, а не слом.
> Мы хотим идти своим уникальным путём и у нас есть ресурсы, чтобы
> подменять сложившиеся практики на Ruby. Ради одного пакета? Серьёзно?
> 
> Есть ещё вариант: удалить пакеты Ruby и собирать забандленными.

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

Я уверен, что это так и есть.

--
  wbr,
    iv m.

Re: [devel] Зависимости ruby-libs и libruby

[Dmitry V. Levin]

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

On Sun, Jan 20, 2019 at 03:31:33PM +0300, Dmitry V. Levin wrote:
[...]
> Какой-то откровенный бардак теперь с этим ruby.

Просьба опубликовать план прекращения этого бардака.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby

[Anton Farygin]

28.01.2019 23:24, Aleksey Novodvorsky пишет:
>
>
>     С точки зрения инфраструктуры Ruby это как раз исправление, а не слом.
>
> У нас своя инфраструктура. Инфраструктуру Ruby надо встраивать в нее, 
> а не ломать ей нашу. Если непонятно как, то надо советоваться.
>
>
>
>      Мы хотим идти своим уникальным путём и у нас есть ресурсы, чтобы
>     подменять сложившиеся практики на Ruby. Ради одного пакета? Серьёзно?
>
>     Есть ещё вариант: удалить пакеты Ruby и собирать забандленными.
>
> Есть разные варианты, но ломать нельзя.
>
> И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если 
> да -- соберите, а если нет, то зачем опакечивать gems?

  У ruby есть ещё один отличный тест на систему сборки - это опакеченный 
redmine.

Когда-то давным давно он у нас был.

Re: [devel] Зависимости ruby-libs и libruby

[Eugene Prokopiev]

вт, 29 янв. 2019 г. в 07:36, Anton Farygin <rider@basealt.ru>:

> > И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если
> > да -- соберите, а если нет, то зачем опакечивать gems?
>
>   У ruby есть ещё один отличный тест на систему сборки - это опакеченный
> redmine.
>
> Когда-то давным давно он у нас был.

Это уже удар ниже пояса :) Но добавлю: для кучи java-пакетов тоже есть
такой тест - опакеченный eclipse :)

-- 
WBR,
Eugene Prokopiev

Re: [devel] undeclared ruby packaging policy change

[Dmitry V. Levin]

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

On Tue, Jan 29, 2019 at 07:12:43AM +0300, Andrey Cherepanov wrote:
[...]
> Примечание: я про схему rubygems вообще, наш автопоиск на require... возник позже, а затем 17 сентября 2018 года вернулся к апстримному и принятому ведущими дистрибутивами (той же Fedora). Скоро полгода (!) перехода на эту схему будем отмечать.

К сожалению, это изменение прошло незамеченным для всех,
кроме непосредственно вовлеченных в реализацию изменения.

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

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

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

В той же Федоре нет автопоиска зависимостей в shell-скриптах и
скриптлетах, ввиду чего там принято зависимости на grep и sed писать
вручную, но вряд ли было бы разумным нам отказываться от shell.req.

Отказ от автопоиска зависимостей на ruby только потому, что в Федоре этого
не осилили -- это действие того же рода, что и отказ от автопоиска
зависимостей в shell-скриптах.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby

[Anton Farygin]

29.01.2019 7:12, Andrey Cherepanov пишет:
>
>
> 29 января 2019 г. 6:56:54 GMT+03:00, Andrey Cherepanov 
> <cas@altlinux.org> пишет:
>
>
>
>
>     Эта схема старее, чем искусственные костыли с Ruby, на которые
>     предлагает вернутся shaba@.
>
>
> Примечание: я про схему rubygems вообще, наш автопоиск на require... 
> возник позже, а затем 17 сентября 2018 года вернулся к апстримному и 
> принятому ведущими дистрибутивами (той же Fedora). Скоро полгода (!) 
> перехода на эту схему будем отмечать.


$ rpm -qR ruby-stdlibs
libyaml2
libgdbm
libssl1.1
libcrypto1.1
gem(rubygems-update) >= 3.0.1
gem(did_you_mean) >= 1.3.0
gem(minitest) >= 5.11.3
gem(net-telnet) >= 0.2
gem(power_assert) >= 1.1.3
gem(rake) >= 12.3.2
gem(test-unit) >= 3.2.9
gem(xmlrpc) >= 0.3.0
gem(rdoc) >= 6.1.1
libruby = 2.5.4-alt2:sisyphus+219587.400.1.1
rpmlib(PayloadIsLzma)

Из этого списка интересны, в первую очередь, rubygems-update, rake, 
minitest, test-unit, rdoc,did_you_mean  . Непонятно зачем оно нужно в 
stdlibs.

Кстати, видимо потому что gem заработал - теперь можно и вот так:
$ gem update
Updating installed gems
Updating bigdecimal
Fetching: bigdecimal-1.4.3.gem (100%)
ERROR:  While executing gem ... (Gem::FilePermissionError)
     You don't have write permissions for the /usr/lib/ruby/gems/2.5.0 
directory.

Re: [devel] Зависимости ruby-libs и libruby

[Anton Farygin]

29.01.2019 10:16, Eugene Prokopiev пишет:
> вт, 29 янв. 2019 г. в 07:36, Anton Farygin <rider@basealt.ru>:
>
>>> И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если
>>> да -- соберите, а если нет, то зачем опакечивать gems?
>>    У ruby есть ещё один отличный тест на систему сборки - это опакеченный
>> redmine.
>>
>> Когда-то давным давно он у нас был.
> Это уже удар ниже пояса :) Но добавлю: для кучи java-пакетов тоже есть
> такой тест - опакеченный eclipse :)
>
Наоборот - как раз новая схема упаковки ruby пакетов может значительно 
облегчить жизнь ментейнера и позволит упакетить более тяжёлые приложения.

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

Re: [devel] Зависимости ruby-libs и libruby

[Vladimir D. Seleznev]

On Tue, Jan 29, 2019 at 11:48:08AM +0300, Anton Farygin wrote:
> 29.01.2019 10:16, Eugene Prokopiev пишет:
> > вт, 29 янв. 2019 г. в 07:36, Anton Farygin <rider@basealt.ru>:
> >
> >>> И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если
> >>> да -- соберите, а если нет, то зачем опакечивать gems?
> >>    У ruby есть ещё один отличный тест на систему сборки - это опакеченный
> >> redmine.
> >>
> >> Когда-то давным давно он у нас был.
> > Это уже удар ниже пояса :) Но добавлю: для кучи java-пакетов тоже есть
> > такой тест - опакеченный eclipse :)
> >
> Наоборот - как раз новая схема упаковки ruby пакетов может значительно 
> облегчить жизнь ментейнера и позволит упакетить более тяжёлые приложения.
> 
> Не совсем понятно, как предлагается выкручиваться с требованием разных 
> версий у разных приложений.

Если проблема разных версий у зависимостей на модули руби стоит так
остро, то тогда надо разные версии модулей руби разносить по путям,
чтобы не было конфликтов и, например, хардкодить версию модуля в имя
пакета. И собирать несколько версий модуля. При этом не забывать
периодически чистить репозитории от тех модулей, которых более никто не
требует.

> Ну и совсем непонятно, что делать с кучей левого софта, быстро
> втягиваемого в базовую систему через ruby зависимости.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby

[Dmitry V. Levin]

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

On Tue, Jan 29, 2019 at 11:48:08AM +0300, Anton Farygin wrote:
[...]
> Не совсем понятно, как предлагается выкручиваться с требованием разных 
> версий у разных приложений.

В федоре для этого сделали следующее:

- сняли требование, чтобы каждый пакет в каждый момент времени был только
  одной эпохи:версии-релиза;
- реализовали и внедрили Boolean Dependencies [1] в rpm, dnf, libsolv,
  и где-то ещё;
- поменяли правила упаковки пакетов.

Я на днях довольно долго разговаривал с теми людьми, которые реализовывали
эти Boolean Dependencies в rpm и dnf.  Пока что у меня сложилось ощущение,
что они зря пошли этим извилистым путём.

Обращаю ваше внимание на следующий параграф в Fedora Ruby Packaging Guidelines [2]:

"Patching required gem versions

One common patching need is to change overly strict version requirements
in the upstream .gemspec. This could be because upstream’s .gemspec only
mentions versions that they’ve explicitly tested against but we know that
a different version will also work or because we know that the packages we
ship have applied fixes for problematic behavior without bumping the
version number (for instance, backported fixes). To adjust such
dependencies, you can use the %gemspec_add_dep and %gemspec_remove_dep
macros."

[1] http://rpm.org/user_doc/boolean_dependencies.html
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_patching_required_gem_versions


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] undeclared ruby packaging policy change

[Dmitry V. Levin]

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

On Tue, Jan 29, 2019 at 11:32:24AM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 29, 2019 at 07:12:43AM +0300, Andrey Cherepanov wrote:
> [...]
> > Примечание: я про схему rubygems вообще, наш автопоиск на require... возник позже, а затем 17 сентября 2018 года вернулся к апстримному и принятому ведущими дистрибутивами (той же Fedora). Скоро полгода (!) перехода на эту схему будем отмечать.
> 
> К сожалению, это изменение прошло незамеченным для всех,
> кроме непосредственно вовлеченных в реализацию изменения.
> 
> Теперь вам придётся сделать то, что вы должны были сделать с самого
> начала: подробно изложить недостатки действовавших на тот момент правил,
> подробно изложить, почему и как вы хотите это изменить, и подробно
> рассказать, что делать всем мантейнерам, которым не повезло быть
> затронутым этим изменением.
> 
> Возможно, из-за того, что изменения готовились кулуарно, вы упустили
> из виду важные последствия, которые могут ключевым образом повлиять
> на принятое решение.
> 
> Примеры других дистрибутивов тоже интересны, конечно, но совершенно
> необязательно являются примерами для подражания.
> 
> В той же Федоре нет автопоиска зависимостей в shell-скриптах и
> скриптлетах, ввиду чего там принято зависимости на grep и sed писать
> вручную, но вряд ли было бы разумным нам отказываться от shell.req.
> 
> Отказ от автопоиска зависимостей на ruby только потому, что в Федоре этого
> не осилили -- это действие того же рода, что и отказ от автопоиска
> зависимостей в shell-скриптах.

Для справки.

Наше текущее Ruby Packaging Policy, актуальность которого
после ваших необъявленных изменений вызывает сомнения:
https://www.altlinux.org/Ruby_Policy

Fedora Ruby Packaging Guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/

The current packaging practices for Ruby in Debian:
https://wiki.debian.org/Teams/Ruby/Packaging

openSUSE Ruby Packaging Guidelines:
https://en.opensuse.org/openSUSE:Packaging_Ruby


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

29.01.2019, 12:14, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Tue, Jan 29, 2019 at 11:48:08AM +0300, Anton Farygin wrote:
>>  29.01.2019 10:16, Eugene Prokopiev пишет:
>>  > вт, 29 янв. 2019 г. в 07:36, Anton Farygin <rider@basealt.ru>:
>>  >
>>  >>> И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если
>>  >>> да -- соберите, а если нет, то зачем опакечивать gems?
>>  >> У ruby есть ещё один отличный тест на систему сборки - это опакеченный
>>  >> redmine.
>>  >>
>>  >> Когда-то давным давно он у нас был.
>>  > Это уже удар ниже пояса :) Но добавлю: для кучи java-пакетов тоже есть
>>  > такой тест - опакеченный eclipse :)
>>  >
>>  Наоборот - как раз новая схема упаковки ruby пакетов может значительно
>>  облегчить жизнь ментейнера и позволит упакетить более тяжёлые приложения.
>>
>>  Не совсем понятно, как предлагается выкручиваться с требованием разных
>>  версий у разных приложений.
>
> Если проблема разных версий у зависимостей на модули руби стоит так
> остро, то тогда надо разные версии модулей руби разносить по путям,
> чтобы не было конфликтов и, например, хардкодить версию модуля в имя
> пакета. И собирать несколько версий модуля. При этом не забывать
> периодически чистить репозитории от тех модулей, которых более никто не
> требует.
>
Проблема совместимости версий на основе анализа всех наших проектов на языке рубе писанных, так остро не стоит, и пока ни разу не потребовалось делать совместимые пакеты, ограничились лишь правкой версий в зависимостях пары гемов.

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

28.01.2019, 23:11, "Ivan A. Melnikov" <iv@altlinux.org>:
> On Mon, Jan 28, 2019 at 10:44:17PM +0300, Andrey Cherepanov wrote:
>>  28 января 2019 г. 22:30:51 GMT+03:00, Aleksey Novodvorsky <aen@altlinux.ru> пишет:
>>  >понедельник, 28 января 2019 г. пользователь Andrey Cherepanov <
>>  >cas@altlinux.org> написал:
>>  >
>>  >> 28 января 2019 г. 22:06:03 GMT+03:00, Alexey Shabalin <
>>  >> a.shabalin@gmail.com> пишет:
>
> [...]
>>  >>> А в пакете из сизифа пусто, как будто ничего не требуется.
>>  >>> У меня совсем нет желания выяснять вручную имена пакетов.
>>  >>>
>>  >> Побудь добрым врачом, лечащим безбашенный апстрим. Тем более в
>>  >> единичном экземпляре.
>>  >>
>>  > Кто сломал, тот и лечит.
>>  >
>>
>>  С точки зрения инфраструктуры Ruby это как раз исправление, а не слом.
>>  Мы хотим идти своим уникальным путём и у нас есть ресурсы, чтобы
>>  подменять сложившиеся практики на Ruby. Ради одного пакета? Серьёзно?
>>
>>  Есть ещё вариант: удалить пакеты Ruby и собирать забандленными.
>
> Я надеюсь, что имелось ввиду, что разработчики новой инфраструктуры
> должны быть готовы помочь пакетам, оказавшимся на обочине прогресса,
> этот прогресс догнать; помочь и добрым словом, и патчами.
>
> Я уверен, что это так и есть.

Так и есть.


-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Скрылевъ Малъ]

29.01.2019, 07:36, "Anton Farygin" <rider@basealt.ru>:
> 28.01.2019 23:24, Aleksey Novodvorsky пишет:
>>      С точки зрения инфраструктуры Ruby это как раз исправление, а не слом.
>>
>>  У нас своя инфраструктура. Инфраструктуру Ruby надо встраивать в нее,
>>  а не ломать ей нашу. Если непонятно как, то надо советоваться.
>>
>>       Мы хотим идти своим уникальным путём и у нас есть ресурсы, чтобы
>>      подменять сложившиеся практики на Ruby. Ради одного пакета? Серьёзно?
>>
>>      Есть ещё вариант: удалить пакеты Ruby и собирать забандленными.
>>
>>  Есть разные варианты, но ломать нельзя.
>>
>>  И ещё. Есть очень простой тест. Вы можете собрать Geyser в пакет? Если
>>  да -- соберите, а если нет, то зачем опакечивать gems?
>
>   У ruby есть ещё один отличный тест на систему сборки - это опакеченный
> redmine.

Вполне можно и обновить.

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby

[Vitaly Chikunov]

On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
> 
> > Гемы и "модули по старинке" не одним и тем-же require подцепляются?
> > Следовательно, нет никакой разницы "что именно они представляют" и
> > в какие папки попадает.
> 
> Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.

Если не одним и тем же require, то разные, а если одним и тем же, то не
важно где они лежат.

Но, я хочу развить эту мысль:

> Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
> Например, модуль для руби скорее всего относится к руби, а не к гему.
> Модуль для rails к rails, а не к gem или rubyapps.

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

Наподобие того как есть суффиксы -static -devel и т.д. Например
ruby-memcached-gem - значит этот пакет упадет в дерево гемов.

В таком варианте остается желанный префикс ruby, не меняется полиси в
этом отношении и добавляются отсылки к gem.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
> On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
>>  > Гемы и "модули по старинке" не одним и тем-же require подцепляются?
>>  > Следовательно, нет никакой разницы "что именно они представляют" и
>>  > в какие папки попадает.
>>
>>  Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.
>
> Если не одним и тем же require, то разные, а если одним и тем же, то не
> важно где они лежат.
>
> Но, я хочу развить эту мысль:
>
>>  Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
>>  Например, модуль для руби скорее всего относится к руби, а не к гему.
>>  Модуль для rails к rails, а не к gem или rubyapps.
>
> Так как gem-ы это всего лишь вид паковки, то (согласно моей идее) его
> нужно добавлять не как префикс, а как суффикс к названию пакета.
>
Принципиально я не против суффикса -gem. Однако есть 2 замечания:

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

второе объясню на примере:
есть вот пакет libyajl из исходника yajl, будет логически конфликтовать в похожим на него бисером с таким же названием и суффиксом "-gem".


> Наподобие того как есть суффиксы -static -devel и т.д. Например
> ruby-memcached-gem - значит этот пакет упадет в дерево гемов.
>
> В таком варианте остается желанный префикс ruby, не меняется полиси в
> этом отношении и добавляются отсылки к gem.

Собственно вот проект документа новой политики руби, о котором была речь на совещании:

https://www.altlinux.org/Ruby_Policy_2.0

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vladimir D. Seleznev]

On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
> 
> 
> 01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
> > On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
> >>  > Гемы и "модули по старинке" не одним и тем-же require подцепляются?
> >>  > Следовательно, нет никакой разницы "что именно они представляют" и
> >>  > в какие папки попадает.
> >>
> >>  Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.
> >
> > Если не одним и тем же require, то разные, а если одним и тем же, то не
> > важно где они лежат.
> >
> > Но, я хочу развить эту мысль:
> >
> >>  Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
> >>  Например, модуль для руби скорее всего относится к руби, а не к гему.
> >>  Модуль для rails к rails, а не к gem или rubyapps.
> >
> > Так как gem-ы это всего лишь вид паковки, то (согласно моей идее) его
> > нужно добавлять не как префикс, а как суффикс к названию пакета.
> >
> Принципиально я не против суффикса -gem. Однако есть 2 замечания:
> 
> первое это то, что изменение префикса на суффикс, додаст бардака в принципы формирования пакетов, хотя бы потому, что в подсистемах перла и пифона, по сю пору используются префиксы.
> 
> второе объясню на примере:
> есть вот пакет libyajl из исходника yajl, будет логически конфликтовать в похожим на него бисером с таким же названием и суффиксом "-gem".
> 
> 
> > Наподобие того как есть суффиксы -static -devel и т.д. Например
> > ruby-memcached-gem - значит этот пакет упадет в дерево гемов.
> >
> > В таком варианте остается желанный префикс ruby, не меняется полиси в
> > этом отношении и добавляются отсылки к gem.
> 
> Собственно вот проект документа новой политики руби, о котором была речь на совещании:
> 
> https://www.altlinux.org/Ruby_Policy_2.0

Вместо префикса gem- и суффикса -gem для наглядности лучше использовать
префикс rubygem-. Нерубишникам будет понятно, что пакет относится к
руби, рубишники увидят, что собирается модуль из gem'ов.

По политике.
Если в путях модулей, собранных из RubyGems есть версия Ruby
(/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
этой версии. Если у нас не предполагается держать несколько версий руби
в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на

    requires ruby >= 2.5.0

надо добавлять конфликты

    conflicts ruby >= 2.6.0

а также писать эту версию в префиксе имени модуля:
rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
участников команды devel@, как в случае наличия версии интерпретатора в
путях модулей действовать.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

05.02.2019 19:34, Vladimir D. Seleznev пишет:
> On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
>>
>> 01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
>>> On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
>>>
>      requires ruby >= 2.5.0
>
> надо добавлять конфликты
>
>      conflicts ruby >= 2.6.0
>
> а также писать эту версию в префиксе имени модуля:
> rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> участников команды devel@, как в случае наличия версии интерпретатора в
> путях модулей действовать.
>
Очень плохая идея держать несколько версий языка и кучу модулей для 
каждой из них в тех случаях, когда этого можно было бы не делать. 
Кардинально усложняется сборка прикладного софта и вносится путаница в 
зависимости.


Я  с год назад с этим боролся в окамл - там была проблема в том, что 
часть модулей было собрано для ocaml4, часть - для ocaml-3. В итоге ни 
то ни другое толком не работало. После объединения - у нас есть один 
ocaml-4.07.1, к которому собрано некоторое количество модулей (ничего 
лишнего, всё только нужное).

Минус такого подхода - необходимость полной пересборки этого хозяйства с 
каждой новой версией. Но у нас инструменты для такой пересборки 
улучшаются с каждым днём и я вообще не вижу в этом проблемы.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vladimir D. Seleznev]

On Tue, Feb 05, 2019 at 08:00:27PM +0300, Anton Farygin wrote:
> 05.02.2019 19:34, Vladimir D. Seleznev пишет:
> > On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
> >>
> >> 01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
> >>> On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
> >>>
> >      requires ruby >= 2.5.0
> >
> > надо добавлять конфликты
> >
> >      conflicts ruby >= 2.6.0
> >
> > а также писать эту версию в префиксе имени модуля:
> > rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> > участников команды devel@, как в случае наличия версии интерпретатора в
> > путях модулей действовать.
> >
> Очень плохая идея держать несколько версий языка и кучу модулей для 
> каждой из них в тех случаях, когда этого можно было бы не делать. 
> Кардинально усложняется сборка прикладного софта и вносится путаница в 
> зависимости.

Моё письмо как раз о том, что мы не собираемся держать несколько Ruby в
репозитории. Тем не менее, в модулях RubyGems в путях присутствует
версия, и если не ужесточить зависимость на конкретный диапазон версий
интерпретатора, то проблем будет не меньше.

> Я  с год назад с этим боролся в окамл - там была проблема в том, что 
> часть модулей было собрано для ocaml4, часть - для ocaml-3. В итоге ни 
> то ни другое толком не работало. После объединения - у нас есть один 
> ocaml-4.07.1, к которому собрано некоторое количество модулей (ничего 
> лишнего, всё только нужное).
> 
> Минус такого подхода - необходимость полной пересборки этого хозяйства с 
> каждой новой версией. Но у нас инструменты для такой пересборки 
> улучшаются с каждым днём и я вообще не вижу в этом проблемы.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

05.02.2019 17:44, Скрылевъ Малъ пишет:
> Собственно вот проект документа новой политики руби, о котором была речь на совещании:
>
> https://www.altlinux.org/Ruby_Policy_2.0

В документе используется терминология, которая мне непонятна.

Например - бисер. Этот термин кто придумал и зачем ? Для вашего текста 
нужен отдельный толковый словарь.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

05.02.2019, 19:35, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
>>  01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
>>  > On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
>>  >>  > Гемы и "модули по старинке" не одним и тем-же require подцепляются?
>>  >>  > Следовательно, нет никакой разницы "что именно они представляют" и
>>  >>  > в какие папки попадает.
>>  >>
>>  >>  Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.
>>  >
>>  > Если не одним и тем же require, то разные, а если одним и тем же, то не
>>  > важно где они лежат.
>>  >
>>  > Но, я хочу развить эту мысль:
>>  >
>>  >>  Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
>>  >>  Например, модуль для руби скорее всего относится к руби, а не к гему.
>>  >>  Модуль для rails к rails, а не к gem или rubyapps.
>>  >
>>  > Так как gem-ы это всего лишь вид паковки, то (согласно моей идее) его
>>  > нужно добавлять не как префикс, а как суффикс к названию пакета.
>>  >
>>  Принципиально я не против суффикса -gem. Однако есть 2 замечания:
>>
>>  первое это то, что изменение префикса на суффикс, додаст бардака в принципы формирования пакетов, хотя бы потому, что в подсистемах перла и пифона, по сю пору используются префиксы.
>>
>>  второе объясню на примере:
>>  есть вот пакет libyajl из исходника yajl, будет логически конфликтовать в похожим на него бисером с таким же названием и суффиксом "-gem".
>>
>>  > Наподобие того как есть суффиксы -static -devel и т.д. Например
>>  > ruby-memcached-gem - значит этот пакет упадет в дерево гемов.
>>  >
>>  > В таком варианте остается желанный префикс ruby, не меняется полиси в
>>  > этом отношении и добавляются отсылки к gem.
>>
>>  Собственно вот проект документа новой политики руби, о котором была речь на совещании:
>>
>>  https://www.altlinux.org/Ruby_Policy_2.0
>
> Вместо префикса gem- и суффикса -gem для наглядности лучше использовать
> префикс rubygem-. Нерубишникам будет понятно, что пакет относится к
> руби, рубишники увидят, что собирается модуль из gem'ов.
>

rubygem- очень длинно. Понятие "Gem" само по себе достаточно уникальное явление в мире разработки,чтобы его с чем-то можно было спутать, а узнать о значении оного не очень проблема.

> По политике.
> Если в путях модулей, собранных из RubyGems есть версия Ruby
> (/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
> этой версии. Если у нас не предполагается держать несколько версий руби
> в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на
>
>     requires ruby >= 2.5.0
>
> надо добавлять конфликты
>
>     conflicts ruby >= 2.6.0
>

там ставится жесткая зависимость на ruby(2.5.0)

> а также писать эту версию в префиксе имени модуля:
> rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> участников команды devel@, как в случае наличия версии интерпретатора в
> путях модулей действовать.
>
> --
>    С уважением,
>    Владимир Селезнев
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

05.02.2019, 19:35, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:

> По политике.
> Если в путях модулей, собранных из RubyGems есть версия Ruby
> (/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
> этой версии. Если у нас не предполагается держать несколько версий руби
> в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на
>
>     requires ruby >= 2.5.0
>
> надо добавлять конфликты
>
>     conflicts ruby >= 2.6.0
>
> а также писать эту версию в префиксе имени модуля:
> rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> участников команды devel@, как в случае наличия версии интерпретатора в
> путях модулей действовать.

Володя, я в политике явно не прописал, но на деле такие зависимости выставляются уже автоматически.

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

05.02.2019, 19:35, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
>>  01.02.2019, 09:40, "Vitaly Chikunov" <vt@altlinux.org>:
>>  > On Mon, Jan 28, 2019 at 10:45:27PM +0300, Скрылевъ Малъ wrote:
>>  >>  > Гемы и "модули по старинке" не одним и тем-же require подцепляются?
>>  >>  > Следовательно, нет никакой разницы "что именно они представляют" и
>>  >>  > в какие папки попадает.
>>  >>
>>  >>  Одним и тем же require, однако side_ruby модули не видны в дереве гемов. Так что разные.
>>  >
>>  > Если не одним и тем же require, то разные, а если одним и тем же, то не
>>  > важно где они лежат.
>>  >
>>  > Но, я хочу развить эту мысль:
>>  >
>>  >>  Было бы логично, чтоб в префиксе указывалось то к чему относится модуль.
>>  >>  Например, модуль для руби скорее всего относится к руби, а не к гему.
>>  >>  Модуль для rails к rails, а не к gem или rubyapps.
>>  >
>>  > Так как gem-ы это всего лишь вид паковки, то (согласно моей идее) его
>>  > нужно добавлять не как префикс, а как суффикс к названию пакета.
>>  >
>>  Принципиально я не против суффикса -gem. Однако есть 2 замечания:
>>
>>  первое это то, что изменение префикса на суффикс, додаст бардака в принципы формирования пакетов, хотя бы потому, что в подсистемах перла и пифона, по сю пору используются префиксы.
>>
>>  второе объясню на примере:
>>  есть вот пакет libyajl из исходника yajl, будет логически конфликтовать в похожим на него бисером с таким же названием и суффиксом "-gem".
>>
>>  > Наподобие того как есть суффиксы -static -devel и т.д. Например
>>  > ruby-memcached-gem - значит этот пакет упадет в дерево гемов.
>>  >
>>  > В таком варианте остается желанный префикс ruby, не меняется полиси в
>>  > этом отношении и добавляются отсылки к gem.
>>
>>  Собственно вот проект документа новой политики руби, о котором была речь на совещании:
>>
>>  https://www.altlinux.org/Ruby_Policy_2.0
>
> Вместо префикса gem- и суффикса -gem для наглядности лучше использовать
> префикс rubygem-. Нерубишникам будет понятно, что пакет относится к
> руби, рубишники увидят, что собирается модуль из gem'ов.
>
> По политике.
> Если в путях модулей, собранных из RubyGems есть версия Ruby
> (/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
> этой версии. Если у нас не предполагается держать несколько версий руби
> в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на
>
>     requires ruby >= 2.5.0
>
> надо добавлять конфликты
>
>     conflicts ruby >= 2.6.0
>
> а также писать эту версию в префиксе имени модуля:
> rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> участников команды devel@, как в случае наличия версии интерпретатора в
> путях модулей действовать.

Политика подправлена.

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vladimir D. Seleznev]

On Tue, Feb 05, 2019 at 08:13:04PM +0300, Скрылевъ Малъ wrote:
> > Вместо префикса gem- и суффикса -gem для наглядности лучше использовать
> > префикс rubygem-. Нерубишникам будет понятно, что пакет относится к
> > руби, рубишники увидят, что собирается модуль из gem'ов.
> >
> 
> rubygem- очень длинно. Понятие "Gem" само по себе достаточно
> уникальное явление в мире разработки,чтобы его с чем-то можно было
> спутать, а узнать о значении оного не очень проблема.
> 
> > По политике.
> > Если в путях модулей, собранных из RubyGems есть версия Ruby
> > (/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
> > этой версии. Если у нас не предполагается держать несколько версий руби
> > в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на
> >
> >     requires ruby >= 2.5.0
> >
> > надо добавлять конфликты
> >
> >     conflicts ruby >= 2.6.0
> >
> 
> там ставится жесткая зависимость на ruby(2.5.0)

Взял первый попавшийся модуль:

$ hsh-run -- rpm -qR gem-did-you-mean
ruby >= 2.5.0
rubygems >= 0
rpmlib(PayloadIsLzma)

Не вижу ruby(2.5.0). Как же так?

> > а также писать эту версию в префиксе имени модуля:
> > rubygem2.5.0-modulename. Хотя тут надо спросить совета у более опытных
> > участников команды devel@, как в случае наличия версии интерпретатора в
> > путях модулей действовать.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

05.02.2019, 21:13, "Vladimir D. Seleznev" <vseleznv@altlinux.org>:
> On Tue, Feb 05, 2019 at 08:13:04PM +0300, Скрылевъ Малъ wrote:
>>  > Вместо префикса gem- и суффикса -gem для наглядности лучше использовать
>>  > префикс rubygem-. Нерубишникам будет понятно, что пакет относится к
>>  > руби, рубишники увидят, что собирается модуль из gem'ов.
>>  >
>>
>>  rubygem- очень длинно. Понятие "Gem" само по себе достаточно
>>  уникальное явление в мире разработки,чтобы его с чем-то можно было
>>  спутать, а узнать о значении оного не очень проблема.
>>
>>  > По политике.
>>  > Если в путях модулей, собранных из RubyGems есть версия Ruby
>>  > (/usr/lib/ruby/gems/2.5.0/), то значит, что эти модули жёстко зависят от
>>  > этой версии. Если у нас не предполагается держать несколько версий руби
>>  > в репозитории/системе, то, пожалуй, помимо зависимостей в RubyGems на
>>  >
>>  >     requires ruby >= 2.5.0
>>  >
>>  > надо добавлять конфликты
>>  >
>>  >     conflicts ruby >= 2.6.0
>>  >
>>
>>  там ставится жесткая зависимость на ruby(2.5.0)
>
> Взял первый попавшийся модуль:
>
> $ hsh-run -- rpm -qR gem-did-you-mean
> ruby >= 2.5.0
> rubygems >= 0
> rpmlib(PayloadIsLzma)
>
> Не вижу ruby(2.5.0). Как же так?

Ну так что это пока только проект политики не утвержденный, потому и пакетов там таких трудно найти.
-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Grigory Ustinov]

05.02.2019 20:07, Anton Farygin пишет:
> 05.02.2019 17:44, Скрылевъ Малъ пишет:
>> Собственно вот проект документа новой политики руби, о котором была 
>> речь на совещании:
>>
>> https://www.altlinux.org/Ruby_Policy_2.0
>
> В документе используется терминология, которая мне непонятна.
>
> Например - бисер. Этот термин кто придумал и зачем ? Для вашего текста 
> нужен отдельный толковый словарь.

Я специально изучил этот вопрос: Один из переводов слова gem - это 
жемчужина. А в древнецерковнославянском словом "бисьръ" как раз и 
называли жемчуг. Слово жемчуг для использования в тексте не приемлемо, 
потому что оно происходит из тюркских языков. Хотя если честно, то уж 
куда понятнее было бы называть гемы самоцветами.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Dmitry V. Levin]

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

On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
[...]
> Собственно вот проект документа новой политики руби, о котором была речь на совещании:
> 
> https://www.altlinux.org/Ruby_Policy_2.0

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

06.02.2019 0:38, Grigory Ustinov пишет:
> 05.02.2019 20:07, Anton Farygin пишет:
>> 05.02.2019 17:44, Скрылевъ Малъ пишет:
>>> Собственно вот проект документа новой политики руби, о котором была 
>>> речь на совещании:
>>>
>>> https://www.altlinux.org/Ruby_Policy_2.0
>>
>> В документе используется терминология, которая мне непонятна.
>>
>> Например - бисер. Этот термин кто придумал и зачем ? Для вашего 
>> текста нужен отдельный толковый словарь.
>
> Я специально изучил этот вопрос: Один из переводов слова gem - это 
> жемчужина. А в древнецерковнославянском словом "бисьръ" как раз и 
> называли жемчуг. Слово жемчуг для использования в тексте не приемлемо, 
> потому что оно происходит из тюркских языков. Хотя если честно, то уж 
> куда понятнее было бы называть гемы самоцветами. 

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton V. Boyarshinov]

В Wed, 6 Feb 2019 00:38:00 +0300
Grigory Ustinov <grenka@altlinux.org> пишет:

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

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

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Dmitry V. Levin]

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

On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
> On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
> [...]
> > Собственно вот проект документа новой политики руби, о котором была речь на совещании:
> > 
> > https://www.altlinux.org/Ruby_Policy_2.0
> 
> Пожалуйста, не надо переводить слова ruby и gem на русский язык
> в технической документации.

Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
в технической документации.

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

Кажется, в обоснование отказа от нашей многолетней практики
автоматического вычисления ruby-зависимостей в приложениях по require
в тексте продвигается идея, будто все приложения перешли на Gemfile и
require больше не используются.

Опыт исправления пострадавшего пакета opennebula показывает, что это не так.
Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
автоматического вычисления ruby-зависимостей в приложениях по require
опубликовать список всех пакетов, которые в результате этого изменения
теряют зависимости и требуют ручного исправления.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

Пожалуй нужно пояснить мой подход.

Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
* я привык к русскому языку, а не английскому, в том числе в технической документации;
* такое именование оно вполне себе продолжает школы как дореволюционную инженерную, так и советскую разработческую. скажем по сю пору в ЕСПД есть такие термины как: цепочка (string), управление/управляющий (control), обслуживание (utility), переместимый (relocatible), тупик (deadlock), проверка (checkout), испытание (test), закрытый (encapsulated), старшинство (precedence).

11.02.2019, 15:51, "Dmitry V. Levin" <ldv@altlinux.org>:
> On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
>
> Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
> в технической документации.
>

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


> Прочитать текст в его нынешнем виде, испещрённом бисерами,
> не представляется возможным.
>
> Кажется, в обоснование отказа от нашей многолетней практики
> автоматического вычисления ruby-зависимостей в приложениях по require
> в тексте продвигается идея, будто все приложения перешли на Gemfile и
> require больше не используются.
>

Так и есть, используются require, только на основе прописанного списка бисеров явно.

> Опыт исправления пострадавшего пакета opennebula показывает, что это не так.
> Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
> автоматического вычисления ruby-зависимостей в приложениях по require
> опубликовать список всех пакетов, которые в результате этого изменения
> теряют зависимости и требуют ручного исправления.

Опыт упаковки "постраждавшего" пакета ничем не отличается от подобных бисеров или проектов на Gemfile. Скажем если говорить об "opennebula",то такой пакет должен был, иметь по сути 1 пакет с зависимостями на основе Gemfile, и скажем называться ruby-opennebula, и 2 пакета с бисерами (opennebula) и (opennebula-cli). Однако вышел только один пакет ruby-openbebula и иные пакеты  Алексей рассек на несколько частей и подпакетов этот основной рубишный, по каким-то своим причинам, растащив при этом и исполняемые файлы, что однако, не может служить правилом определения зависимостей для такой схемы, хотя бы потому, возможны прямые пересечения вызовов модулей в такой схеме, причем модулей не из внешних источников. Потому для такой схемы следует не определять зависимости автоматически, а вписывать их руками, есть также вариант просто сочинить нужные Gemfile-ы, хотя в этом проекте они есть.

-- 
С уважением,
 Скрылевъ Малъ
+79055245451

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vitaly Chikunov]

On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> 
> Пожалуй нужно пояснить мой подход.
> 
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким
> причинам: * я привык к русскому языку, а не английскому, в том числе в
> технической документации; * такое именование оно вполне себе
> продолжает школы как дореволюционную инженерную, так и советскую
> разработческую. скажем по сю пору в ЕСПД есть такие термины как:
> цепочка (string), управление/управляющий (control), обслуживание
> (utility), переместимый (relocatible), тупик (deadlock), проверка
> (checkout), испытание (test), закрытый (encapsulated), старшинство
> (precedence).

Ruby и gem имена собственные.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Fr. Br. George]

On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> 
> Пожалуй нужно пояснить мой подход.
> 
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> * я привык к русскому языку, а не английскому, в том числе в технической документации;
> * такое именование оно вполне себе продолжает школы как дореволюционную инженерную, так и советскую разработческую. скажем по сю пору в ЕСПД есть такие термины как: цепочка (string), управление/управляющий (control), обслуживание (utility), переместимый (relocatible), тупик (deadlock), проверка (checkout), испытание (test), закрытый (encapsulated), старшинство (precedence).
> 
> Я не против вернуть англоязычные термины (на английском конечно), хотя скажем для меня читать тексты изобилующие изводами букв двух языков напрягает, да и с таким же успехом можно было и сразу писать весь текст по-английски, а в свете грядущего "импортозамещения", а также изложенных доводов о терминологии в сов-время, это представляется мягко говоря недальновидным. мы же по-русски говорим, верно? Я в принципе могу и по-английски написать эти определения.

Мы говорим не по-русски, мы говорим на компьютерном арго. И это не от
недостатка русскости или грамотности, просто арго обеспечивается более
однозначное и быстрое толкование терминов всему сообществу.

Если для понимания терминологии необходимо будет дополнительно изучать
«дореволюционную инженерную, так и советскую разработческую»
терминологию, или даже ЕСПД, это оттолкнёт большую часть потенциальных
наших коллег.

Для профессионального арго характерно наличие макаронизмов, именно
в силу их однозначности.

Кроме того, Ruby является именем собственным, и по правилам русского
языка не переводится, а при необходимости транслитерируется,
с использованием прописной буквы: Руби.

Хочу заметить, что такие допущенные в обсуждаемом документе латинизмы,
эллинизмы и прочие англицизмы, как «модуль», «библиотека», «пакет» (оба
в отношении программного продукта), «файл», «проект», «интерпретация» (в
отношении работы ЯП), «архитектура» (в отншении типа аппаратного
обеспечения), «компиляция», «версия» (в значении «номер»),
«спецификация», «макросы» (что в свою очередь является ощибочным
употерблением множественного числа от «макро», это как «Битлзы»),
«автоматизация» (в значении машинного выполнения) и некоторые другие,
_значительно облегчают_ его понимание.

Соответственно, неожиданное замещение арготизмов самостоятельно
изобретёнными или унаследованными из позапрошлого столетия терминами это
понимание усложняет.

-- 
	Fr. Br. George

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Michael Shigorin]

On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:

Ты для себя пишешь или для других?  Если второе -- то предлагаю
подход "кесарю кесарево".

> Потому для такой схемы следует не определять зависимости
> автоматически, а вписывать их руками, есть также вариант просто
> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.

Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
регрессия.  Было, работало, сломали.  Ради чего?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Paul Wolneykien]

11.02.2019 17:27, Скрылевъ Малъ пишет:
> 
> Пожалуй нужно пояснить мой подход.
> 
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:

11.02.2019 18:08, Vitaly Chikunov пишет:
> Ruby и gem имена собственные.

  Относительно Руби — скорее всего да. А вот со словом "gem" ситуация,
на мой взгляд, похуже.

11.02.2019 18:09, Fr. Br. George пишет:
> Мы говорим не по-русски, мы говорим на компьютерном арго.
> ...просто арго обеспечивается более
> однозначное и быстрое толкование терминов всему сообществу.

  Вот и с "gem" похожая история. Только "gem" — это даже не компьютерное
арго, это — слово из узкоспециализированного жаргона сообщества Руби.
Жаргона (насколько я успел разобраться) не возникшего естественным путём
в разговорной практике, а привнесённого в человеческий язык менеджером
пакетов "RubyGems". Следовательно, жаргона авторского (!),
искусственного происхождения. Одно это обстоятельство ставит под
сомнение право гражданства этого словечка в любом человеческом языке.
Однако практика употребления уже расставила всё по местам — слово "gem"
прижилось в сообществе и в этом отношении уже вряд ли можно и нужно
что-то менять.

  Для чего это могло понадобиться сообществу Руби? В принципе, цель
"однозначное и быстрое толкование терминов" сюда подходит. Ещё более
вероятно — организация быстрого и однозначного поиска по ключевым
словам. Здесь я исхожу из того, что поисковый запрос "how to install
'foobar' gem?" будет давать больше релевантных результатов, чем "how to
install 'foobar' Ruby package". Особенно на ранней стадии развития
сообщества. Т.е. интернет большой, языков программирования много,
сообществ тоже, пакетов просто завались — вот и понадобилось ключевое слово.

  Если это так (а я думаю, что это отчасти так), то получается, что
слово "gem" никак нельзя заменять на другое слово и, вероятно, нельзя
даже транслитерировать. Использование вместо него слова "бисер" [кстати,
а как в этом случае быть со множественным числом?] требует, как минимум,
написания альтернативного менеджера пакетов с именем "Бисер" и открытие
репозитория пакетов Руби по адресу http://бисер.рф/. Только после этого
можно пытаться начинать говорить о том, что это такое ключевое слово,
которым для однозначности пользуются пользователи данного репозитория,
задавая вопросы типа "Как нанизать бисер 'foobar' на свою систему?"
В противном случае, пока такого менеджера пакетов и репозитория нет, как
нет и сообщества их пользователей, использование "бисер" вместо "gem"
работает против однозначности, и, вместо того чтобы сплачивать
сообщество Руби воедино, откалывает от него кусочек адептов "бисера"
(кстати сказать, сколько их уже?)

  Теперь о второй части. Глядя на те же "яйца питона" (вид сбоку),
хочется сказать, что лидеры некоторых проектов преследуют не вполне
понятные мне цели превращения проекта в подобие секты или организации
заговорщиков. Вполне допускаю, что они просто не доиграли в детстве в
шпионов или что-нибудь вроде этого. Короче говоря, в некоторых проектах
явно прослеживаются мотивы подхода к инженерной работе как подобию
творческой игры, свойственные, между прочим, исключительно западной
(скорее даже англосаксонской) культуре (со всей её обширной литературой
на эту тему). В связи с этим даже странно предлагать продолжать эту
линию после ссылок на —

11.02.2019 17:27, Скрылевъ Малъ пишет:
> * я привык к русскому языку, а не английскому, в том числе в технической документации;
> * такое именование оно вполне себе продолжает школы как дореволюционную инженерную,> так и советскую разработческую. скажем по сю пору в ЕСПД

  Особенно вторая * вряд ли подразумевает подход к работе как к игре (в
том числе как к игре в забавные термины).

> есть такие термины как: цепочка (string), управление/управляющий (control), обслуживание (utility), переместимый (relocatible), тупик (deadlock), проверка (checkout), испытание (test), закрытый (encapsulated), старшинство (precedence).

  А ещё в этом списке есть слово "пакет". Что позволяет перевести "Ruby
package" как "пакет Руби".

> а в свете грядущего "импортозамещения", а также изложенных доводов о терминологии в сов-время, это представляется мягко говоря недальновидным.

  Но в этом свете замена "gem" на "бисер" получается уже даже вредной.
Понятно, что ряд отечественных разработок начинался с заимствования
иностранных образцов. Но если иметь в виду настоящие разработки,
которыми можно гордиться, то следует заметить, что заимствование в этих
случаях было творческим, а сама разработка уходила от своего
предка-копии далеко вперёд. А вы что предлагаете? Ограничиться
русификацией термина? Но тем самым вы уже сразу постулируете тот
плачевный результат "импортозамещения", который частенько мы видим на
практике — когда всё "замещение" сводится к замене таблички (а "своё
производство" — к закупке импортных компонентов).

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Grigory Ustinov]

11.02.2019 18:09, Fr. Br. George пишет:
> Хочу заметить, что такие допущенные в обсуждаемом документе латинизмы,
> эллинизмы и прочие англицизмы, как «модуль», «библиотека», «пакет» (оба
> в отношении программного продукта), «файл», «проект», «интерпретация» (в
> отношении работы ЯП), «архитектура» (в отншении типа аппаратного
> обеспечения), «компиляция», «версия» (в значении «номер»),
> «спецификация», «макросы» (что в свою очередь является ощибочным
> употерблением множественного числа от «макро», это как «Битлзы»),
> «автоматизация» (в значении машинного выполнения) и некоторые другие,
> _значительно облегчают_  его понимание.
Я хочу заметить, что текст вызывает дикие приступы смеха, которые плавно 
переходят в огорчение от непонимания. Как говорится "смешно, но не 
понятно" (с). Тем не менее, как заметил Георгий, какие-то отдельные 
слова же случайно или намеренно оставлены быть понятными. То есть 
смех-то вызывает не великий могучий русский язык, а именно 
неконсистентность текста. Если угодно аналогию, он как пюре с твёрдыми 
кусочками. А по сему, я лично вижу два варианта:

1.) Смириться с использованием англоязычных слов в сфере ИТ и поправить 
в данной статье непонятные слова на понятные, кстати это касается не 
только терминов, но и некоторых других слов и окончаний.

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

П.С. Хочу так же заметить, что под эту древнецерковнославянскую машину 
переводов угораздило и наш любимый P.A.O. С каждым обновлением он 
"хорошеет и преображается". Там уже есть "сопроводители", "ветви" и 
"надзор"-файлы. Благо, там есть английская версия, где вроде бы всё ещё 
осталось по-прежнему.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Denis Medvedev]

On понедельник, 11 февраля 2019 г. 18:09:59 MSK Fr. Br. George wrote:
> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> > Пожалуй нужно пояснить мой подход.
> > 
> > Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> > * я привык к русскому языку, а не английскому, в том числе в технической
> > документации; * такое именование оно вполне себе продолжает школы как
> > дореволюционную инженерную, так и советскую разработческую. скажем по сю
> > пору в ЕСПД есть такие термины как: цепочка (string),
> > управление/управляющий (control), обслуживание (utility), переместимый
> > (relocatible), тупик (deadlock), проверка (checkout), испытание (test),
> > закрытый (encapsulated), старшинство (precedence).
> > 
> > Я не против вернуть англоязычные термины (на английском конечно), хотя
> > скажем для меня читать тексты изобилующие изводами букв двух языков
> > напрягает, да и с таким же успехом можно было и сразу писать весь текст
> > по-английски, а в свете грядущего "импортозамещения", а также изложенных
> > доводов о терминологии в сов-время, это представляется мягко говоря
> > недальновидным. мы же по-русски говорим, верно? Я в принципе могу и
> > по-английски написать эти определения.
> Мы говорим не по-русски, мы говорим на компьютерном арго. И это не от
> недостатка русскости или грамотности, просто арго обеспечивается более
> однозначное и быстрое толкование терминов всему сообществу.
> 
> Если для понимания терминологии необходимо будет дополнительно изучать
> «дореволюционную инженерную, так и советскую разработческую»
> терминологию, или даже ЕСПД, это оттолкнёт большую часть потенциальных
> наших коллег.
> 
> Для профессионального арго характерно наличие макаронизмов, именно
> в силу их однозначности.
> 
> Кроме того, Ruby является именем собственным, и по правилам русского
> языка не переводится, а при необходимости транслитерируется,
> с использованием прописной буквы: Руби.
> 
> Хочу заметить, что такие допущенные в обсуждаемом документе латинизмы,
> эллинизмы и прочие англицизмы, как «модуль», «библиотека», «пакет» (оба
> в отношении программного продукта), «файл», «проект», «интерпретация» (в
> отношении работы ЯП), «архитектура» (в отншении типа аппаратного
> обеспечения), «компиляция», «версия» (в значении «номер»),
> «спецификация», «макросы» (что в свою очередь является ощибочным
> употерблением множественного числа от «макро», это как «Битлзы»),
> «автоматизация» (в значении машинного выполнения) и некоторые другие,
> _значительно облегчают_ его понимание.
> 
> Соответственно, неожиданное замещение арготизмов самостоятельно
> изобретёнными или унаследованными из позапрошлого столетия терминами это
> понимание усложняет.
Хочу только дополнить что и термины из русского при выбранном подходе 
взяты неуклюже:
"бисер" в русском языке означает россыпь мелких предметов,
gem же явно один и целен.  Он "камень", "камушек" если уж на то пошло.
А Ruby - ну никак ни Руби! Он Рубин! Сразу представляется яркий красный
камень, в то же время Руби ассоциируется максимум  с иностранно звучащей
кличкой собаки.

Re: [devel] [JT] Зависимости ruby-libs и libruby и новая политика 2.0

[Fr. Br. George]

On Tue, Feb 12, 2019 at 08:49:42AM +0300, Denis Medvedev wrote:
> А Ruby - ну никак ни Руби! Он Рубин!
Нет, Денис, имена собственные не переводятся. Даже Питон на самом деле
следует писать и произносить «Пайтон», но «Питон» вроде как привился.
Может, и Рубин привьётся, не знаю, но пока звучит диковато.

-- 
	Fr. Br. George

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Cherepanov]

11.02.2019 22:50, Michael Shigorin пишет:
> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> Ты для себя пишешь или для других?  Если второе -- то предлагаю
> подход "кесарю кесарево".
Поддерживаю.
>
>> Потому для такой схемы следует не определять зависимости
>> автоматически, а вписывать их руками, есть также вариант просто
>> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
> Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
> регрессия.  Было, работало, сломали.  Ради чего?

Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод? Ты
собирал сам Ruby? Ты сможешь прокомментировать причины отказа от старой
схемы? Ты моделировал поведение разработчика на Ruby? Так зачем делать
такие категоричные суждения?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Savchenko]

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

On Tue, 12 Feb 2019 09:44:37 +0300 Andrey Cherepanov wrote:
> 11.02.2019 22:50, Michael Shigorin пишет:
> > On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> >> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> > Ты для себя пишешь или для других?  Если второе -- то предлагаю
> > подход "кесарю кесарево".
> Поддерживаю.
> >
> >> Потому для такой схемы следует не определять зависимости
> >> автоматически, а вписывать их руками, есть также вариант просто
> >> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
> > Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
> > регрессия.  Было, работало, сломали.  Ради чего?
> 
> Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод? Ты
> собирал сам Ruby?

Я собирал Ruby на e2k и обеспечил возможность бутстрапа на другие
новые архитектуры, чем люди уже пользовались. И могу утверждать,
что нынешнее действие выглядит примерно так: мы упростим себе
поддержку ruby и инфраструктуры модулей ruby (т.е. gem) за счёт
отказа от автоматического определения зависимостей в пакетах,
использующих ruby (но не обязательно являющихся gem). Т.е. по сути
дела речь идёт о перекладывании проблем с плеч мейнтенеров ruby на
плечи мейнтенеров не-gem пакетов, использующих ruby.

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

Best regards,
Andrew Savchenko

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Savchenko]

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

On Mon, 11 Feb 2019 17:27:18 +0300 Скрылевъ Малъ wrote:
> 
> Пожалуй нужно пояснить мой подход.
> 
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> * я привык к русскому языку, а не английскому, в том числе в технической документации;

Павел, ты работаешь в коллективе, где есть определённые нормы
работы, в т.ч. ведения документации. Англоязычная терминология —
стандарт де факто в IT-отрасли, нравится это кому-то или нет,
потому что такой язык понятен подавляющему большинству
специалистов. Поэтому данного стандарта нужно придерживаться.

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

> * такое именование оно вполне себе продолжает школы как
> дореволюционную инженерную, так и советскую разработческую. скажем
> по сю пору в ЕСПД есть такие термины как: цепочка (string),
> управление/управляющий (control), обслуживание (utility),
> переместимый (relocatible), тупик (deadlock), проверка (checkout),
> испытание (test), закрытый (encapsulated), старшинство (precedence).

Лингвистические упражнения — это, бесусловно, полезно
и занимательно, но я бы попросил заниматься ими в другом месте.

Best regards,
Andrew Savchenko

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

Re: [devel] [JT] Зависимости ruby-libs и libruby и новая политика 2.0

[Oleg Solovyov]

On вторник, 12 февраля 2019 г. 8:56:37 MSK Fr. Br. George wrote:
> Даже Питон на самом деле следует писать и произносить «Пайтон»
Монти Пайтон и терминология Ruby

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Ivan A. Melnikov]

On Tue, Feb 12, 2019 at 09:44:37AM +0300, Andrey Cherepanov wrote:
> 11.02.2019 22:50, Michael Shigorin пишет:
> > On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> >> Потому для такой схемы следует не определять зависимости
> >> автоматически, а вписывать их руками, есть также вариант просто
> >> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
> > Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
> > регрессия.  Было, работало, сломали.  Ради чего?
> 
> Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод?

Вот у меня достаточно опыта внешнего наблюдения чтобы сделать вывод,
что для внешнего наблюдателя это выглядит именно так.

> Ты собирал сам Ruby? Ты сможешь прокомментировать причины отказа от
> старой схемы? Ты моделировал поведение разработчика на Ruby?

К сожелению люди, которые всё это проделали, не сочли нужным
поделиться своим анализом с сообществом. Напоминать при этом
про действующую https://www.altlinux.org/Policy_Policy
кажется уже почти бестактным.

В Ruby Policy 2.0 этого анализа тоже нет, а обоснование
изменений сводится к довольно короткому подразделу
"Сравнение с предыдущей политикою". Кстати, в нём я
совершенно не распарсил грамматику в половине пунктов,
особенно в этом:

| для Gemfile проектов потому, что вызовы require являются
| неявными и выполняются bundler-ом опосредованно на основе
| анализа Gemfile и .gemspec если таковой присутствует. также
| bundler следит за тем, чтобы среда и окружение разработки
| таких проектов были целостными, это приводит к том, что
| вызов require к внешнему модулю при необъявленная
| зависимость на него в Gemfile, приведет к критическому
| затруднения разработки проекта;

В общем, ответ на предъявленный выше вопрос "Ради чего?" я
могу только попробовать угадать.

Также, пункт "Правила перехода на схему сию" описывает 
только переход для пакетов, представляющих собой запаковыные
gem'ы. Как мы выяснили, не все ruby-пакеты таковы, однако
последствия и способы исправления этих последствий для
прочих пакетов не описаны.

Случай opennebula показывает, что в Сизифе появился новый
класс сломаных пакетов -- пакеты, потерявшие нужные им
зависимости из-за перехода на новую схему поиска
зависимостей в ruby. Этот случай также не описан в политике.
Также по всей видимости масштабы проблемы остаются
неизвестными.

--
  wbr,
    iv m.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Cherepanov]

12.02.2019 9:55, Andrey Savchenko пишет:
> On Tue, 12 Feb 2019 09:44:37 +0300 Andrey Cherepanov wrote:
>> 11.02.2019 22:50, Michael Shigorin пишет:
>>> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>>> Ты для себя пишешь или для других?  Если второе -- то предлагаю
>>> подход "кесарю кесарево".
>> Поддерживаю.
>>>> Потому для такой схемы следует не определять зависимости
>>>> автоматически, а вписывать их руками, есть также вариант просто
>>>> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
>>> Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
>>> регрессия.  Было, работало, сломали.  Ради чего?
>> Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод? Ты
>> собирал сам Ruby?
> Я собирал Ruby на e2k и обеспечил возможность бутстрапа на другие
> новые архитектуры, чем люди уже пользовались. И могу утверждать,
> что нынешнее действие выглядит примерно так: мы упростим себе
> поддержку ruby и инфраструктуры модулей ruby (т.е. gem) за счёт
> отказа от автоматического определения зависимостей в пакетах,
> использующих ruby (но не обязательно являющихся gem). Т.е. по сути
> дела речь идёт о перекладывании проблем с плеч мейнтенеров ruby на
> плечи мейнтенеров не-gem пакетов, использующих ruby.
>
> Такой подход можно понять, но я считаю его неверным, поскольку он
> нарушает принцип автоопределения зависимостей, которому издавна
> следуют в Альте.
Хорошо, все умные и этично выверенные, предложите, что именно делать,
как избежать проблемы с требование старых пакетов и расхождения API и
пересобрите несколько сотен пакетов. Вы же точно знаете, как нужно жить
(правда, вспоминаете об этом раз в полгода). Кто будет правильным
мейнтейнером пакетов Ruby (как raorn, который плевать хотел на то, что и
как используют разработчики Ruby)? Я (думаю, Павел тоже не откажется) с
удовольствием передадим им мейнтейнерство.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

12.02.2019, 09:55, "Andrey Savchenko" <bircoph@altlinux.org>:
> On Tue, 12 Feb 2019 09:44:37 +0300 Andrey Cherepanov wrote:
>>  11.02.2019 22:50, Michael Shigorin пишет:
>>  > On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>  >> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>>  > Ты для себя пишешь или для других? Если второе -- то предлагаю
>>  > подход "кесарю кесарево".
>>  Поддерживаю.
>>  >
>>  >> Потому для такой схемы следует не определять зависимости
>>  >> автоматически, а вписывать их руками, есть также вариант просто
>>  >> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
>>  > Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
>>  > регрессия. Было, работало, сломали. Ради чего?
>>
>>  Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод? Ты
>>  собирал сам Ruby?
>
> Я собирал Ruby на e2k и обеспечил возможность бутстрапа на другие
> новые архитектуры, чем люди уже пользовались. И могу утверждать,
> что нынешнее действие выглядит примерно так: мы упростим себе
> поддержку ruby и инфраструктуры модулей ruby (т.е. gem) за счёт
> отказа от автоматического определения зависимостей в пакетах,
> использующих ruby (но не обязательно являющихся gem). Т.е. по сути
> дела речь идёт о перекладывании проблем с плеч мейнтенеров ruby на
> плечи мейнтенеров не-gem пакетов, использующих ruby.
>
> Такой подход можно понять, но я считаю его неверным, поскольку он
> нарушает принцип автоопределения зависимостей, которому издавна
> следуют в Альте.

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

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


-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

11.02.2019, 18:10, "Fr. Br. George" <george@altlinux.org>:
> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>  Пожалуй нужно пояснить мой подход.
>>
>>  Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>>  * я привык к русскому языку, а не английскому, в том числе в технической документации;
>>  * такое именование оно вполне себе продолжает школы как дореволюционную инженерную, так и советскую разработческую. скажем по сю пору в ЕСПД есть такие термины как: цепочка (string), управление/управляющий (control), обслуживание (utility), переместимый (relocatible), тупик (deadlock), проверка (checkout), испытание (test), закрытый (encapsulated), старшинство (precedence).
>>
>>  Я не против вернуть англоязычные термины (на английском конечно), хотя скажем для меня читать тексты изобилующие изводами букв двух языков напрягает, да и с таким же успехом можно было и сразу писать весь текст по-английски, а в свете грядущего "импортозамещения", а также изложенных доводов о терминологии в сов-время, это представляется мягко говоря недальновидным. мы же по-русски говорим, верно? Я в принципе могу и по-английски написать эти определения.
>
> Мы говорим не по-русски, мы говорим на компьютерном арго. И это не от
> недостатка русскости или грамотности, просто арго обеспечивается более
> однозначное и быстрое толкование терминов всему сообществу.
>
> Если для понимания терминологии необходимо будет дополнительно изучать
> «дореволюционную инженерную, так и советскую разработческую»
> терминологию, или даже ЕСПД, это оттолкнёт большую часть потенциальных
> наших коллег.
>
> Для профессионального арго характерно наличие макаронизмов, именно
> в силу их однозначности.
>
> Кроме того, Ruby является именем собственным, и по правилам русского
> языка не переводится, а при необходимости транслитерируется,
> с использованием прописной буквы: Руби.
>
> Хочу заметить, что такие допущенные в обсуждаемом документе латинизмы,
> эллинизмы и прочие англицизмы, как «модуль», «библиотека», «пакет» (оба
> в отношении программного продукта), «файл», «проект», «интерпретация» (в
> отношении работы ЯП), «архитектура» (в отншении типа аппаратного
> обеспечения), «компиляция», «версия» (в значении «номер»),
> «спецификация», «макросы» (что в свою очередь является ощибочным
> употерблением множественного числа от «макро», это как «Битлзы»),
> «автоматизация» (в значении машинного выполнения) и некоторые другие,
> _значительно облегчают_ его понимание.
>
> Соответственно, неожиданное замещение арготизмов самостоятельно
> изобретёнными или унаследованными из позапрошлого столетия терминами это
> понимание усложняет.

Вопрос в том, что слов гем и джем нет ни в  русском, да и в "арго", а термин требует русскоязычной замены, в случае с вышеозначенными понятиями типа "макрос", тогда было выбрано именно такое слово, в других случаях другое, в данном случае это видимо зависит от настроенности человека употребляющего подобные понятия, настроенности либо на заимствования, либо на перевод или включение новых понятий из диалектных форм языка,  скажем так, как это была на заре зарождения современной литературной формы оного в пору Державина, Карамзина и позднее Пушкина. 

Что касается употребление в сообществе, то можно скажем взглянуть на терминологию статей хабра, много интересного можно уведать :)

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

11.02.2019, 22:50, "Michael Shigorin" <mike@altlinux.org>:
> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>  Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>
> Ты для себя пишешь или для других? Если второе -- то предлагаю
> подход "кесарю кесарево".
>

Миша, ты используешь сейчас такой достаточно манипулятивный подход хода конем, если не это, то то. Как водится так бывает в нынешнем мире не часто, более того "кесарю кесарево" это подход разделения религиозного и политического. Если ты имел ввиду, что нельзя смешивать писание для себя и для других, так я думаю как раз не то, что можно, а и нужно. Скажем даже в апостольской проповеди присутствовали оба элемента они знали как правильно, но при этом часто шли в людям на их условиях, но не всей полноте, а лишь в том, что было не принципиально, остальное же оставляли как были научены ничто смущаясь. Здесь же речь идет всего лишь о понятиях еще не устоявшихся в русском языке, хотя скажем и устойчивость выражения, тоже имеет известную стабильность в языке, притом не абсолютную.

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

Например, ради приложений использующих Gemfile, а это все рельсовые приложения, синатровые, и скажем opennebula. Я тут писал, писал о них, чем никто не читает, зато все увидели бисер :)

В нынешнюю пору в сизифе схему с Gemfile используют: 

foreman
puppet
chef
opennebula (с не вполне попыткой сборки)

в планах geyser.

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

12.02.2019, 10:19, "Andrey Savchenko" <bircoph@altlinux.org>:
> On Mon, 11 Feb 2019 17:27:18 +0300 Скрылевъ Малъ wrote:
>>  Пожалуй нужно пояснить мой подход.
>>
>>  Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>>  * я привык к русскому языку, а не английскому, в том числе в технической документации;
>
> Павел, ты работаешь в коллективе, где есть определённые нормы
> работы, в т.ч. ведения документации. Англоязычная терминология —
> стандарт де факто в IT-отрасли, нравится это кому-то или нет,
> потому что такой язык понятен подавляющему большинству
> специалистов. Поэтому данного стандарта нужно придерживаться.
>

De-facto (по-русски "на деле") все-таки при всем уважении к этому понятию, сам по себе не является стандартом. Потому ссылаться на него, не вполне разумно. А англоязычная терминология не вполне может отвечать запросам именования понятий в русском языке, точнее даже не может. Скажем если употреблять понятия написанные латиницею, то это затрудняет чтение, благодаря постоянном переключению разума между языками и написаниями слов. А обрусеные же заимствования вообще не желательны, поскольку засоряются понятиями язык, причем часто вводя дополнительные омонимы, напр. в случае использования слова "джем".


> Вообще, на мой взгляд, техническая документация (как минимум в IT)
> должна быть на английском, чтоб её мог понять любой специалист.
> Документация для русскоязычного пользователя, безусловно, должна
> делаться на русском, но речь сейчас не про неё.

Лучше к делу, так писать политику на английском или нет?



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton V. Boyarshinov]

On Mon, 11 Feb 2019 17:27:18 +0300 Скрылевъ Малъ wrote:

>
> * такое именование оно вполне себе продолжает школы как
> дореволюционную инженерную, так и советскую разработческую. скажем по
> сю пору в ЕСПД есть такие термины как: цепочка (string),
> управление/управляющий (control), обслуживание (utility),
> переместимый (relocatible), тупик (deadlock), проверка (checkout),
> испытание (test), закрытый (encapsulated), старшинство (precedence).
Очень хороший набор примеров. Он наглядно демонстрирует вопиющую
неудачность и контринтуитивность как минимум половины вышеприведённых
терминов (цепочка, обслуживание, тупик, проверка, закрытый).

Эти термины были более-менее пригодны для советских НИИ, работники
которых были практически лишены возможности общения со своими
иностранными коллегами (и, зачастую, не знали английского языка,
как, например, мои родители, проработавшие программистами всю жизнь).
Впрочем, даже они не употребляли вне формальных контекстов ублюдочные
термины вроде "НЖМД". Но мы, к счастью, находимся в совершенно другом
положении.

> 
> 11.02.2019, 15:51, "Dmitry V. Levin" <ldv@altlinux.org>:
> > On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
> >
> > Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
> > в технической документации.
> >  
> 
> Я не против вернуть англоязычные термины (на английском конечно), хотя скажем для меня читать тексты изобилующие изводами букв двух языков напрягает, да и с таким же успехом можно было и сразу писать весь текст по-английски, а в свете грядущего "импортозамещения", а также изложенных доводов о терминологии в сов-время, это представляется мягко говоря недальновидным. мы же по-русски говорим, верно? Я в принципе могу и по-английски написать эти определения.
> 
> 
> > Прочитать текст в его нынешнем виде, испещрённом бисерами,
> > не представляется возможным.
> >
> > Кажется, в обоснование отказа от нашей многолетней практики
> > автоматического вычисления ruby-зависимостей в приложениях по require
> > в тексте продвигается идея, будто все приложения перешли на Gemfile и
> > require больше не используются.
> >  
> 
> Так и есть, используются require, только на основе прописанного списка бисеров явно.
> 
> > Опыт исправления пострадавшего пакета opennebula показывает, что это не так.
> > Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
> > автоматического вычисления ruby-зависимостей в приложениях по require
> > опубликовать список всех пакетов, которые в результате этого изменения
> > теряют зависимости и требуют ручного исправления.  
> 
> Опыт упаковки "постраждавшего" пакета ничем не отличается от подобных бисеров или проектов на Gemfile. Скажем если говорить об "opennebula",то такой пакет должен был, иметь по сути 1 пакет с зависимостями на основе Gemfile, и скажем называться ruby-opennebula, и 2 пакета с бисерами (opennebula) и (opennebula-cli). Однако вышел только один пакет ruby-openbebula и иные пакеты  Алексей рассек на несколько частей и подпакетов этот основной рубишный, по каким-то своим причинам, растащив при этом и исполняемые файлы, что однако, не может служить правилом определения зависимостей для такой схемы, хотя бы потому, возможны прямые пересечения вызовов модулей в такой схеме, причем модулей не из внешних источников. Потому для такой схемы следует не определять зависимости автоматически, а вписывать их руками, есть также вариант просто сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
> 
> -- 
> С уважением,
>  Скрылевъ Малъ
> +79055245451
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Dmitry V. Levin]

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

On Mon, Feb 11, 2019 at 03:51:00PM +0300, Dmitry V. Levin wrote:
[...]
> Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
> автоматического вычисления ruby-зависимостей в приложениях по require
> опубликовать список всех пакетов, которые в результате этого изменения
> теряют зависимости и требуют ручного исправления.

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

12.02.2019 13:05, Aleksey Novodvorsky пишет:
> Вы лезете в бутылку, но не отвечаете на вопросы. Вылезайте и подумайте 
> над ответами.
> Вот мой старый вопрос. Когда geyser будет собран в пакет? Стало ли это 
> существенно проще, чем ранее?

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

12.02.2019 13:39, Скрылевъ Малъ пишет:
> 11.02.2019, 22:50, "Michael Shigorin"<mike@altlinux.org>:
>> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>   Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
>> Ты для себя пишешь или для других? Если второе -- то предлагаю
>> подход "кесарю кесарево".
>>
> Миша, ты используешь сейчас такой достаточно манипулятивный подход хода конем, если не это, то то. Как водится так бывает в нынешнем мире не часто, более того "кесарю кесарево" это подход разделения религиозного и политического. Если ты имел ввиду, что нельзя смешивать писание для себя и для других, так я думаю как раз не то, что можно, а и нужно. Скажем даже в апостольской проповеди присутствовали оба элемента они знали как правильно, но при этом часто шли в людям на их условиях, но не всей полноте, а лишь в том, что было не принципиально, остальное же оставляли как были научены ничто смущаясь. Здесь же речь идет всего лишь о понятиях еще не устоявшихся в русском языке, хотя скажем и устойчивость выражения, тоже имеет известную стабильность в языке, притом не абсолютную.
>
Пишите уже на английском, понятнее будет.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

12.02.2019 13:45, Скрылевъ Малъ пишет:
> Лучше к делу, так писать политику на английском или нет?

писать _только на английском_. Но желательно без староанглийского и 
старославянского.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Leonid Krivoshein]

12.02.2019 17:01, Anton Farygin пишет:
> 12.02.2019 13:39, Скрылевъ Малъ пишет:
>> 11.02.2019, 22:50, "Michael Shigorin"<mike@altlinux.org>:
>>> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>>   Да, я поименовал ruby как руби, и gem как бисер, по нескольким 
>>>> причинам:
>>> Ты для себя пишешь или для других? Если второе -- то предлагаю
>>> подход "кесарю кесарево".
>>>
>> Миша, ты используешь сейчас такой достаточно манипулятивный подход 
>> хода конем, если не это, то то. Как водится так бывает в нынешнем 
>> мире не часто, более того "кесарю кесарево" это подход разделения 
>> религиозного и политического. Если ты имел ввиду, что нельзя 
>> смешивать писание для себя и для других, так я думаю как раз не то, 
>> что можно, а и нужно. Скажем даже в апостольской проповеди 
>> присутствовали оба элемента они знали как правильно, но при этом 
>> часто шли в людям на их условиях, но не всей полноте, а лишь в том, 
>> что было не принципиально, остальное же оставляли как были научены 
>> ничто смущаясь. Здесь же речь идет всего лишь о понятиях еще не 
>> устоявшихся в русском языке, хотя скажем и устойчивость выражения, 
>> тоже имеет известную стабильность в языке, притом не абсолютную.
>>
> Пишите уже на английском, понятнее будет.

Это ж надо было так затроллить бедное русскоязычное комьюнити!.. :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vladimir D. Seleznev]

On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> 
> Пожалуй нужно пояснить мой подход.
> 
> Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> * я привык к русскому языку, а не английскому, в том числе в технической документации;
> * такое именование оно вполне себе продолжает школы как дореволюционную инженерную, так и советскую разработческую. скажем по сю пору в ЕСПД есть такие термины как: цепочка (string), управление/управляющий (control), обслуживание (utility), переместимый (relocatible), тупик (deadlock), проверка (checkout), испытание (test), закрытый (encapsulated), старшинство (precedence).
> 
> 11.02.2019, 15:51, "Dmitry V. Levin" <ldv@altlinux.org>:
> > On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
> >
> > Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
> > в технической документации.
> >
> 
> Я не против вернуть англоязычные термины (на английском конечно), хотя
> скажем для меня читать тексты изобилующие изводами букв двух языков
> напрягает, да и с таким же успехом можно было и сразу писать весь
> текст по-английски, а в свете грядущего "импортозамещения", а также
> изложенных доводов о терминологии в сов-время, это представляется
> мягко говоря недальновидным. мы же по-русски говорим, верно? Я в
> принципе могу и по-английски написать эти определения.

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

Замечу, что полиси к импортозамещению не имеет никакого отношения. И
хотя сообщество у нас русскоязычное, мне иногда хочется вести всё
сопровождение, включая дополнительную документацию и полиси, на
английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
увеличить охват и сделать более благоприятную среду для привлечение в
сообщество людей, не говорящих по-русски, хотя осознаю, что сообщество
скорее всего будет против полностью переходить на английский.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Aleksey Novodvorsky]

пн, 11 февр. 2019 г. в 15:51, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
> > On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
> > [...]
> > > Собственно вот проект документа новой политики руби, о котором была речь на совещании:
> > >
> > > https://www.altlinux.org/Ruby_Policy_2.0
> >
> > Пожалуйста, не надо переводить слова ruby и gem на русский язык
> > в технической документации.
>
> Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
> в технической документации.
>
> Прочитать текст в его нынешнем виде, испещрённом бисерами,
> не представляется возможным.
>
> Кажется, в обоснование отказа от нашей многолетней практики
> автоматического вычисления ruby-зависимостей в приложениях по require
> в тексте продвигается идея, будто все приложения перешли на Gemfile и
> require больше не используются.
>
> Опыт исправления пострадавшего пакета opennebula показывает, что это не так.

Опыт этот, видимо, не вполне однозначен. Сегодня Павел и Алексей его
обсудили и, возможно, удастся ничем не жертвовать. Давайте немного
подождем.

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

Да, эту задачу в любом случае надо решить, как минимум для проверки вариантов.

Rgrds, Алексей

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Paul Wolneykien]

12.02.2019 22:23, Vladimir D. Seleznev пишет:
> мне иногда хочется вести всё
> сопровождение, включая дополнительную документацию и полиси, на
> английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
> увеличить охват и сделать более благоприятную среду для привлечение в
> сообщество людей, не говорящих по-русски

  Такой эксперимент у нас уже ставился. :-) Кажется, в районе 2010 года
— попробуйте поднять архивы.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Michael Shigorin]

On Tue, Feb 12, 2019 at 10:23:11PM +0300, Vladimir D. Seleznev wrote:
> вельми изобилует вона дивными словесами, неведовыми многиями.

"мнозем" тогда уж, что ли.

> И хотя сообщество у нас русскоязычное, мне иногда хочется вести
> всё сопровождение, включая дополнительную документацию и
> полиси, на английском, a также обсуждение в devel@ и репорты в
> bugzilla, чтобы увеличить охват и сделать более благоприятную
> среду для привлечение в сообщество людей, не говорящих
> по-русски, хотя осознаю, что сообщество скорее всего будет
> против полностью переходить на английский.

Берёшь весы, на одну чашу кладёшь приобретения, на другую --
потери.  Можешь заодно у коллег из PLD проконсультироваться,
много ли им даёт pld-devel-en@ (кажется, единственный знакомый
мне подобный механизм).  Пробуешь на себе, разумеется.

Ещё если тебе делать нечего (rpm там починить, да), то можешь
для начала приложить усилия к давно существующей en.altlinux.org
-- а то я немного задолбался порой это facelift'ить по просьбам
примерно раз в год-другой.  Кстати, тоже могу сконтачить с такими
уникумами -- спросишь, чего именно им не хватало в дебиане/убунте
и федоре/центосе (пусть ещё арчике/гентушечке для почти полноты
картины).

Да, и ещё перейди на овсянку по утрам, это важно.

I just know that language all too well to dislike it thoroughly.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Dmitry V. Levin]

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

On Wed, Feb 13, 2019 at 12:17:37AM +0300, Paul Wolneykien wrote:
> 12.02.2019 22:23, Vladimir D. Seleznev пишет:
> > мне иногда хочется вести всё
> > сопровождение, включая дополнительную документацию и полиси, на
> > английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
> > увеличить охват и сделать более благоприятную среду для привлечение в
> > сообщество людей, не говорящих по-русски
> 
>   Такой эксперимент у нас уже ставился. :-) Кажется, в районе 2010 года
> — попробуйте поднять архивы.

Если кому-то проще сразу писать техническую документацию на английском,
пишите, не вижу в этом проблемы.
Можно начать, например, с commit message'ей, а я посмотрю,
надолго ли вас хватит. :)


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[devel] Administrivia

[Dmitry V. Levin]

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

On Wed, Feb 13, 2019 at 12:33:07AM +0300, Michael Shigorin wrote:
> Ещё если тебе делать нечего (rpm там починить, да), то можешь
> для начала приложить усилия

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Vladimir D. Seleznev]

On Wed, Feb 13, 2019 at 01:17:26AM +0300, Dmitry V. Levin wrote:
> On Wed, Feb 13, 2019 at 12:17:37AM +0300, Paul Wolneykien wrote:
> > 12.02.2019 22:23, Vladimir D. Seleznev пишет:
> > > мне иногда хочется вести всё
> > > сопровождение, включая дополнительную документацию и полиси, на
> > > английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
> > > увеличить охват и сделать более благоприятную среду для привлечение в
> > > сообщество людей, не говорящих по-русски
> > 
> >   Такой эксперимент у нас уже ставился. :-) Кажется, в районе 2010 года
> > — попробуйте поднять архивы.
> 
> Если кому-то проще сразу писать техническую документацию на английском,
> пишите, не вижу в этом проблемы.
> Можно начать, например, с commit message'ей, а я посмотрю,
> надолго ли вас хватит. :)

А что, кто-то пишет commit message'ы не на английском?

-- 
   С уважением,
   Владимир Селезнев

[devel] [JT] engrish

[Michael Shigorin]

On Wed, Feb 13, 2019 at 01:45:45AM +0300, Vladimir D. Seleznev wrote:
> > Можно начать, например, с commit message'ей, а я посмотрю,
> > надолго ли вас хватит. :)
> А что, кто-то пишет commit message'ы не на английском?

Смотря что ещё считать английским (disclaimer: not an American).
Ну и да, технически git умеет не только ASCII в метаданных.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Grigory Ustinov]

13.02.2019 1:45, Vladimir D. Seleznev пишет:
> On Wed, Feb 13, 2019 at 01:17:26AM +0300, Dmitry V. Levin wrote:
>> On Wed, Feb 13, 2019 at 12:17:37AM +0300, Paul Wolneykien wrote:
>>> 12.02.2019 22:23, Vladimir D. Seleznev пишет:
>>>> мне иногда хочется вести всё
>>>> сопровождение, включая дополнительную документацию и полиси, на
>>>> английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
>>>> увеличить охват и сделать более благоприятную среду для привлечение в
>>>> сообщество людей, не говорящих по-русски
>>>    Такой эксперимент у нас уже ставился. :-) Кажется, в районе 2010 года
>>> — попробуйте поднять архивы.
>> Если кому-то проще сразу писать техническую документацию на английском,
>> пишите, не вижу в этом проблемы.
>> Можно начать, например, с commit message'ей, а я посмотрю,
>> надолго ли вас хватит. :)
> А что, кто-то пишет commit message'ы не на английском?

Не хотелось бы вас бесить, нооо... 
http://git.altlinux.org/gears/u/unpaper.git или ещё каноничнее тут: 
http://git.altlinux.org/gears/m/mytetra.git?p=mytetra.git;a=commit;h=fda5cf5d9be41c9816c823fe8d8fb8ed7b554a6d 
. В процессе обновления пакетов я неоднократно натыкался на русские 
коммиты этого гражданина, каждый раз искренне удивляясь. Потому что в 
моём понимании это ничуть не лучше комментариев на русском языке.

Но, увы, попытавшись бегло просмотреть репозиторий на наличие таких вот 
пакетов, я наткнулся на нечто чуть более интересное!!! 
https://packages.altlinux.org/ru/sisyphus/specfiles/ruby-rake - тут 
автор нашего "блаженная полисьи" переводит Ruby как рубин.

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

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

12.02.2019 20:30, Leonid Krivoshein пишет:
>
>
> 12.02.2019 17:01, Anton Farygin пишет:
>> 12.02.2019 13:39, Скрылевъ Малъ пишет:
>>> 11.02.2019, 22:50, "Michael Shigorin"<mike@altlinux.org>:
>>>> On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>>>   Да, я поименовал ruby как руби, и gem как бисер, по нескольким 
>>>>> причинам:
>>>> Ты для себя пишешь или для других? Если второе -- то предлагаю
>>>> подход "кесарю кесарево".
>>>>
>>> Миша, ты используешь сейчас такой достаточно манипулятивный подход 
>>> хода конем, если не это, то то. Как водится так бывает в нынешнем 
>>> мире не часто, более того "кесарю кесарево" это подход разделения 
>>> религиозного и политического. Если ты имел ввиду, что нельзя 
>>> смешивать писание для себя и для других, так я думаю как раз не то, 
>>> что можно, а и нужно. Скажем даже в апостольской проповеди 
>>> присутствовали оба элемента они знали как правильно, но при этом 
>>> часто шли в людям на их условиях, но не всей полноте, а лишь в том, 
>>> что было не принципиально, остальное же оставляли как были научены 
>>> ничто смущаясь. Здесь же речь идет всего лишь о понятиях еще не 
>>> устоявшихся в русском языке, хотя скажем и устойчивость выражения, 
>>> тоже имеет известную стабильность в языке, притом не абсолютную.
>>>
>> Пишите уже на английском, понятнее будет.
>
> Это ж надо было так затроллить бедное русскоязычное комьюнити!.. :)
>
>
Ну понятно было изначально, что идея давать Павлу что-то написать (в том 
числе и commit'ы) - она плоха на корню. Не знаю кто это придумал.

Для коммитов точно надо policy - пусть лучше это будет плохой 
английский, чем плохой старославянский.

Тексты надо писать на понятном языке, если текст написан с 
использованием старославянского - то этот текст как policy считать 
нельзя. Т.е. - де факто policy после обсуждения не принятно просто 
потому что оно нечитаемо. Предлагаю вернуться к этому вопросу после 
переписывания текста на понятном сообществу языке.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Savchenko]

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

On Tue, 12 Feb 2019 13:45:58 +0300 Скрылевъ Малъ wrote:
> 
> 
> 12.02.2019, 10:19, "Andrey Savchenko" <bircoph@altlinux.org>:
> > On Mon, 11 Feb 2019 17:27:18 +0300 Скрылевъ Малъ wrote:
> >>  Пожалуй нужно пояснить мой подход.
> >>
> >>  Да, я поименовал ruby как руби, и gem как бисер, по нескольким причинам:
> >>  * я привык к русскому языку, а не английскому, в том числе в технической документации;
> >
> > Павел, ты работаешь в коллективе, где есть определённые нормы
> > работы, в т.ч. ведения документации. Англоязычная терминология —
> > стандарт де факто в IT-отрасли, нравится это кому-то или нет,
> > потому что такой язык понятен подавляющему большинству
> > специалистов. Поэтому данного стандарта нужно придерживаться.
> >
> 
> De-facto (по-русски "на деле") все-таки при всем уважении к
> этому понятию, сам по себе не является стандартом. Потому ссылаться
> на него, не вполне разумно.

Официально утверждённым — да, обычно не является, общепринятым —
обычно же является, поэтому ссылаться на него можно и нужно.

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

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

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

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

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

> А обрусеные же заимствования вообще не желательны, поскольку
> засоряются понятиями язык, причем часто вводя дополнительные
> омонимы, напр. в случае использования слова "джем".

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

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

Write the policy in English only. In common technical English
please, without ancient or clerical styles or other deviations.

Best regards,
Andrew Savchenko

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Savchenko]

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

On Wed, 13 Feb 2019 04:33:57 +0300 Grigory Ustinov wrote:
> 13.02.2019 1:45, Vladimir D. Seleznev пишет:
> > On Wed, Feb 13, 2019 at 01:17:26AM +0300, Dmitry V. Levin wrote:
> >> On Wed, Feb 13, 2019 at 12:17:37AM +0300, Paul Wolneykien wrote:
> >>> 12.02.2019 22:23, Vladimir D. Seleznev пишет:
> >>>> мне иногда хочется вести всё
> >>>> сопровождение, включая дополнительную документацию и полиси, на
> >>>> английском, a также обсуждение в devel@ и репорты в bugzilla, чтобы
> >>>> увеличить охват и сделать более благоприятную среду для привлечение в
> >>>> сообщество людей, не говорящих по-русски
> >>>    Такой эксперимент у нас уже ставился. :-) Кажется, в районе 2010 года
> >>> — попробуйте поднять архивы.
> >> Если кому-то проще сразу писать техническую документацию на английском,
> >> пишите, не вижу в этом проблемы.
> >> Можно начать, например, с commit message'ей, а я посмотрю,
> >> надолго ли вас хватит. :)
> > А что, кто-то пишет commit message'ы не на английском?
> 
> Не хотелось бы вас бесить, нооо... 
> http://git.altlinux.org/gears/u/unpaper.git или ещё каноничнее тут: 
> http://git.altlinux.org/gears/m/mytetra.git?p=mytetra.git;a=commit;h=fda5cf5d9be41c9816c823fe8d8fb8ed7b554a6d 
> . В процессе обновления пакетов я неоднократно натыкался на русские 
> коммиты этого гражданина, каждый раз искренне удивляясь. Потому что в 
> моём понимании это ничуть не лучше комментариев на русском языке.
> 
> Но, увы, попытавшись бегло просмотреть репозиторий на наличие таких вот 
> пакетов, я наткнулся на нечто чуть более интересное!!! 
> https://packages.altlinux.org/ru/sisyphus/specfiles/ruby-rake - тут 
> автор нашего "блаженная полисьи" переводит Ruby как рубин.

Для описания подобных сообщений в коммитах и changelog в
русском языке есть одно хорошее слово — вредительство.

Нам нужен policy, запрещающий делать описания в коммитах в spec
файлах (как минимум в changelog и комментариях) на не английском
языке.

Best regards,
Andrew Savchenko

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

13.02.2019, 07:57, "Anton Farygin" <rider@basealt.ru>:
> 12.02.2019 20:30, Leonid Krivoshein пишет:
>>  12.02.2019 17:01, Anton Farygin пишет:
>>>  12.02.2019 13:39, Скрылевъ Малъ пишет:
>>>>  11.02.2019, 22:50, "Michael Shigorin"<mike@altlinux.org>:
>>>>>  On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>>>>    Да, я поименовал ruby как руби, и gem как бисер, по нескольким
>>>>>>  причинам:
>>>>>  Ты для себя пишешь или для других? Если второе -- то предлагаю
>>>>>  подход "кесарю кесарево".
>>>>  Миша, ты используешь сейчас такой достаточно манипулятивный подход
>>>>  хода конем, если не это, то то. Как водится так бывает в нынешнем
>>>>  мире не часто, более того "кесарю кесарево" это подход разделения
>>>>  религиозного и политического. Если ты имел ввиду, что нельзя
>>>>  смешивать писание для себя и для других, так я думаю как раз не то,
>>>>  что можно, а и нужно. Скажем даже в апостольской проповеди
>>>>  присутствовали оба элемента они знали как правильно, но при этом
>>>>  часто шли в людям на их условиях, но не всей полноте, а лишь в том,
>>>>  что было не принципиально, остальное же оставляли как были научены
>>>>  ничто смущаясь. Здесь же речь идет всего лишь о понятиях еще не
>>>>  устоявшихся в русском языке, хотя скажем и устойчивость выражения,
>>>>  тоже имеет известную стабильность в языке, притом не абсолютную.
>>>  Пишите уже на английском, понятнее будет.
>>
>>  Это ж надо было так затроллить бедное русскоязычное комьюнити!.. :)
>
> Ну понятно было изначально, что идея давать Павлу что-то написать (в том
> числе и commit'ы) - она плоха на корню. Не знаю кто это придумал.
>
> Для коммитов точно надо policy - пусть лучше это будет плохой
> английский, чем плохой старославянский.
>
> Тексты надо писать на понятном языке, если текст написан с
> использованием старославянского - то этот текст как policy считать
> нельзя. Т.е. - де факто policy после обсуждения не принятно просто
> потому что оно нечитаемо. Предлагаю вернуться к этому вопросу после
> переписывания текста на понятном сообществу языке.

Я дико извиняюсь конечно, но кто набредил про старословянский?)

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

13.02.2019 10:22, Скрылевъ Малъ пишет:
> Я дико извиняюсь конечно, но кто набредил про старословянский?)

Мне не важно на каком диалекте оно написано - важно что это не читаемо.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Скрылевъ Малъ]

13.02.2019, 10:39, "Anton Farygin" <rider@basealt.ru>:
> 13.02.2019 10:22, Скрылевъ Малъ пишет:
>>  Я дико извиняюсь конечно, но кто набредил про старословянский?)
>
> Мне не важно на каком диалекте оно написано - важно что это не читаемо.

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

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

13.02.2019 11:30, Скрылевъ Малъ пишет:
> 13.02.2019, 10:39, "Anton Farygin"<rider@basealt.ru>:
>> 13.02.2019 10:22, Скрылевъ Малъ пишет:
>>>   Я дико извиняюсь конечно, но кто набредил про старословянский?)
>> Мне не важно на каком диалекте оно написано - важно что это не читаемо.
> Не читаемо понятие растяжимое, мне вот не читаемы многие тексты с сети и некоторые тексты в нашей вики, писанные на сухой тех.мове, и что, я буду ругаться с авторами )

Ну в данном случае явно решает большинство ;)

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Sergey Y. Afonin]

On Wednesday 13 February 2019, Скрылевъ Малъ wrote:

> и некоторые тексты в нашей вики, писанные на сухой тех.мове,

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

-- 
С уважением, Сергей Афонин

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Cherepanov]

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

12.02.2019 16:02, Dmitry V. Levin пишет:
> On Mon, Feb 11, 2019 at 03:51:00PM +0300, Dmitry V. Levin wrote:
> [...]
>> Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
>> автоматического вычисления ruby-зависимостей в приложениях по require
>> опубликовать список всех пакетов, которые в результате этого изменения
>> теряют зависимости и требуют ручного исправления.
> Я не знаю, перешли ли уже все проекты на Gemfile или нет, поэтому, повторяю,
> мне нужна правдоподобная оценка множества пакетов, которые придётся починить
> для приведения в соответствие с предлагаемыми правилами.

Перечень пакетов в Sisyphus, которые потеряли зависимости вида
ruby(...), но не провайдят ruby-gem(...), то есть не получают
автозависимости gem'ов:

ldap-user-tools
omnibus
opennebula-context
pcs-pcsd
pcs-pcsd-tests
puppet3
rhc
ruby-berkshelf
ruby-capistrano
ruby-chef-provisioning
ruby-dbus
ruby-dm-aggregates
ruby-dm-core
ruby-eco
ruby-em-mongo
ruby-ffi-inliner
ruby-gettext-utils
ruby-gnome2-devel
ruby-json-pure
ruby-kde4
ruby-ldap
ruby-mcollective-client
ruby-memcache-client
ruby-mkrf
ruby-mongrel
ruby-mongrel_cluster
ruby-qt4
ruby-rexical
ruby-right_aws
ruby-right_http_connection
ruby-rip
ruby-rmagick
ruby-test-spec
ruby-tmail
ruby-warden_strategies
swig-data
userblocker
voodoo

-- 
Andrey Cherepanov
cas@altlinux.org


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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Anton Farygin]

13.02.2019 11:38, Aleksey Novodvorsky пишет:
>
>
>
>
> ср, 13 февр. 2019 г., 11:36 Anton Farygin rider@basealt.ru 
> <mailto:rider@basealt.ru>:
>
>     13.02.2019 11:30, Скрылевъ Малъ пишет:
>     > 13.02.2019, 10:39, "Anton Farygin"<rider@basealt.ru
>     <mailto:rider@basealt.ru>>:
>     >> 13.02.2019 10:22, Скрылевъ Малъ пишет:
>     >>>   Я дико извиняюсь конечно, но кто набредил про старословянский?)
>     >> Мне не важно на каком диалекте оно написано - важно что это не
>     читаемо.
>     > Не читаемо понятие растяжимое, мне вот не читаемы многие тексты
>     с сети и некоторые тексты в нашей вики, писанные на сухой
>     тех.мове, и что, я буду ругаться с авторами )
>
>     Ну в данном случае явно решает большинство ;)
>
>
> Господа, мне кажется, что сейчас вы делаете нечитаемым этот список 
> рассылки .

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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Cherepanov]

11.02.2019 15:51, Dmitry V. Levin пишет:
> On Wed, Feb 06, 2019 at 01:42:51AM +0300, Dmitry V. Levin wrote:
>> On Tue, Feb 05, 2019 at 05:44:09PM +0300, Скрылевъ Малъ wrote:
>> [...]
>>> Собственно вот проект документа новой политики руби, о котором была речь на совещании:
>>>
>>> https://www.altlinux.org/Ruby_Policy_2.0
>> Пожалуйста, не надо переводить слова ruby и gem на русский язык
>> в технической документации.
> Повторяю просьбу: не надо переводить слова ruby и gem на русский язык
> в технической документации.
>
> Прочитать текст в его нынешнем виде, испещрённом бисерами,
> не представляется возможным.
>
> Кажется, в обоснование отказа от нашей многолетней практики
> автоматического вычисления ruby-зависимостей в приложениях по require
> в тексте продвигается идея, будто все приложения перешли на Gemfile и
> require больше не используются.
>
> Опыт исправления пострадавшего пакета opennebula показывает, что это не так.
> Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
> автоматического вычисления ruby-зависимостей в приложениях по require
> опубликовать список всех пакетов, которые в результате этого изменения
> теряют зависимости и требуют ручного исправления.

Перечень пакетов в Sisyphus, которые потеряли зависимости вида
ruby(...), но не провайдят ruby-gem(...), то есть не получают
автозависимости gem'ов:

github2spec
ldap-user-tools
omnibus
opennebula-context
pcs-pcsd
pcs-pcsd-tests
puppet3
rhc
ruby-berkshelf
ruby-capistrano
ruby-chef-provisioning
ruby-dbus
ruby-dm-aggregates
ruby-dm-core
ruby-eco
ruby-em-mongo
ruby-ffi-inliner
ruby-gettext-utils
ruby-gnome2-devel
ruby-json-pure
ruby-kde4
ruby-ldap
ruby-mcollective-client
ruby-memcache-client
ruby-mkrf
ruby-mongrel
ruby-mongrel_cluster
ruby-qt4
ruby-rexical
ruby-right_aws
ruby-right_http_connection
ruby-rip
ruby-rmagick
ruby-test-spec
ruby-tmail
ruby-warden_strategies
swig-data
userblocker
voodoo


P.S. Повторяю список, поскольку был пропущен github2spec. И убираю
подпись GPG.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Leonid Krivoshein]

13.02.2019 10:22, Скрылевъ Малъ пишет:
> 13.02.2019, 07:57, "Anton Farygin" <rider@basealt.ru>:
>> 12.02.2019 20:30, Leonid Krivoshein пишет:
>>>   12.02.2019 17:01, Anton Farygin пишет:
>>>>   12.02.2019 13:39, Скрылевъ Малъ пишет:
>>>>>   11.02.2019, 22:50, "Michael Shigorin"<mike@altlinux.org>:
>>>>>>   On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
>>>>>>>     Да, я поименовал ruby как руби, и gem как бисер, по нескольким
>>>>>>>   причинам:
>>>>>>   Ты для себя пишешь или для других? Если второе -- то предлагаю
>>>>>>   подход "кесарю кесарево".
>>>>>   [...] Если ты имел ввиду, что нельзя
>>>>>   смешивать писание для себя и для других, так я думаю как раз не то,
>>>>>   что можно, а и нужно. [...]

Никакое гнилое слово да не исходит из уст ваших, а только доброе для 
назидания в вере, дабы оно доставляло благодать слушающим.
(Послание к Ефесянам 4:29)


>>>>>   часто шли в людям на их условиях, но не всей полноте, а лишь в том,
>>>>>   что было не принципиально, остальное же оставляли как были научены
>>>>>   ничто смущаясь. [...]

И когда Иисус окончил слова сии, народ дивился учению Его, ибо Он учил 
их, как власть имеющий, а не как книжники и фарисеи.
(Св. Евангелие от Матфея 7:28,29)



-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Dmitry V. Levin]

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

On Wed, Feb 13, 2019 at 11:44:07AM +0300, Andrey Cherepanov wrote:
> 11.02.2019 15:51, Dmitry V. Levin пишет:
[...]
> > Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
> > автоматического вычисления ruby-зависимостей в приложениях по require
> > опубликовать список всех пакетов, которые в результате этого изменения
> > теряют зависимости и требуют ручного исправления.
> 
> Перечень пакетов в Sisyphus, которые потеряли зависимости вида
> ruby(...), но не провайдят ruby-gem(...), то есть не получают
> автозависимости gem'ов:

Которые потеряли зависимости вида ruby(...) и не получили зависимости
вида ruby-gem(...)?
Все эти пакеты уже были собраны по новой схеме и уже потеряли зависимости,
или ещё не все?

> github2spec
> ldap-user-tools
> omnibus
> opennebula-context
> pcs-pcsd
> pcs-pcsd-tests
> puppet3
> rhc
> ruby-berkshelf
> ruby-capistrano
> ruby-chef-provisioning
> ruby-dbus
> ruby-dm-aggregates
> ruby-dm-core
> ruby-eco
> ruby-em-mongo
> ruby-ffi-inliner
> ruby-gettext-utils
> ruby-gnome2-devel
> ruby-json-pure
> ruby-kde4
> ruby-ldap
> ruby-mcollective-client
> ruby-memcache-client
> ruby-mkrf
> ruby-mongrel
> ruby-mongrel_cluster
> ruby-qt4
> ruby-rexical
> ruby-right_aws
> ruby-right_http_connection
> ruby-rip
> ruby-rmagick
> ruby-test-spec
> ruby-tmail
> ruby-warden_strategies
> swig-data
> userblocker
> voodoo

Спасибо.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Fr. Br. George]

On Tue, Feb 12, 2019 at 01:26:04PM +0300, Скрылевъ Малъ wrote:
> Вопрос в том, что слов гем и джем нет ни в  русском, да и в "арго",
Разумеется, есть, их же используют.

> а термин требует русскоязычной замены,
Термин ничего требовать не может.


-- 
	Fr. Br. George

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Andrey Cherepanov]

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

13.02.2019 14:51, Dmitry V. Levin пишет:
> On Wed, Feb 13, 2019 at 11:44:07AM +0300, Andrey Cherepanov wrote:
>> 11.02.2019 15:51, Dmitry V. Levin пишет:
> [...]
>>> Для того, чтобы оценить масштаб бедствия, просьба к автору отказа от
>>> автоматического вычисления ruby-зависимостей в приложениях по require
>>> опубликовать список всех пакетов, которые в результате этого изменения
>>> теряют зависимости и требуют ручного исправления.
>> Перечень пакетов в Sisyphus, которые потеряли зависимости вида
>> ruby(...), но не провайдят ruby-gem(...), то есть не получают
>> автозависимости gem'ов:
> Которые потеряли зависимости вида ruby(...) и не получили зависимости
> вида ruby-gem(...)?
> Все эти пакеты уже были собраны по новой схеме и уже потеряли зависимости,
> или ещё не все?
Эти пакеты были пересобраны большей частью. Фактически они получили
только зависимость на саму ruby (которая раньше провайдила много
ruby(...)), а не формальные зависимости Gemfile/gemspec. Часто
достаточно одного Ruby, но нужно смотреть в каждом конкретном случае.
Полагаю, можно большую часть этого списка собрать как gem и кардинально
сократить список.

-- 
Andrey Cherepanov
cas@altlinux.org


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

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0 [en]

[Скрылевъ Малъ]

https://en.altlinux.org/Ruby/Policy_2.0

-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Зависимости ruby-libs и libruby и новая политика 2.0 [en]

[Скрылевъ Малъ]

18.03.2019, 14:49, "Скрылевъ Малъ" <majioa@yandex.ru>:
> https://en.altlinux.org/Ruby/Policy_2.0
>
это ссылка на англоязычную справу политики ruby)

ныне она более современна неже русскоязычная.

почитайте.
-- 

Малъ Скрылевъ
about.me/majioa