[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