Что такое гемы и как их опакечивать для Gentoo?

Не нужно опакечивать гемы. Эти пакеты должны управляться утилитами gem и bundle входящими в дефолтный комплект поставки Ruby. Грубо говоря, это свой пакетный менеджер.

Ruby-приложения, зависящие от гемов, поставляются с Gemfile и Gemfile.lock файлами, где прописаны конкретные нужные версии пакетов, как package.json и package-json.lock в Javascript. Поэтому пакетирование гемов не имеет смысла, если вы не собираетесь поддерживать тысячи версий одних и тех же пакетов и их зависимостей.

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

Мне нравится происходящее.
Я тут годами пишу, что гента не нужна и вредна, а народ чота спорит, аргументы какие-то пишет (херовые).
А в последнее время хорошо стало, наглядное пособие само с завываниями слоняется по техразделам и отпугивает похлеще спида.

по-хорошему - нет, не отвечает. Например, если есть возможность опакечивать из исходников, почему надо опакечивать из гемов?

По третьей ссылке вроде довольно развёрнуто написано. Пример ebuild есть. Так что отвечает. Хотя допускаю, страничка могла устареть.

gem2ebuild наверное какой-то неофициальный скрипт, не ставший достаточно стабильным и популярным.

Думаю, лучше всё-таки вручную ebuild написать самому.

Более живые примеры можно найти в дереве.

find /var/db/repos/gentoo/ -name "*.ebuild" -exec grep -H USE_RUBY {} \;

Мне 1193 пакета нашло.

Это смотря для чего.

Если чтобы какой-то пакет установить и забыть в систему чтобы пользоваться, то можно и нужно. Можно даже на bugs.gentoo.org его закинуть. Или в неофициальный overlay. Может, кто-то и спасибо скажет.

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

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

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

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

Это меня самого из раза в раз удивляет.

К примеру, YaST в SUSE переписали на Ruby, разумеется не монолитом, а с разделением на кучу модулей, но никому и в голову не пришло реализовать это в виде опакеченных гемов: https://github.com/yast/yast-network

Мне вот интересно, что за осьминоги упорно опакечивают гемы в дебиане

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

Всё правильно делают.

…. так же, как не надо опакечивать модули Go, пакеты npm, артефакты джавы, батарейки rust и армии прочих языков, имеющих собственный пакетный менеджер. (Я на этой стороне)

Но почему-то мейнтейнеры дистрибутивов думают иначе.

Дебиан: модули Go - более тысячи пакетов, такая же тьма npm и т.д….

Федора: модули Go - более 40 тысяч пакетов 🙀

Гента - ну, тут видно…

И т.д., и т.п.

почему-то мейнтейнеры дистрибутивов думают иначе

потому что они тупые и не могут выучить все эти модули, пакеты, артефакты, батарейки и прочие армии. А ты - умный (на этой стороне).

потому что они
А ты -

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

что за осьминоги

Вписались на пионерском задоре опакечивать всякую вебню (дебилы), вот и тащат теперь модули зависимостей. Пусть страдают, таков путь.

Могут начать опакечивать гитхаб. В алфавитном порядке.

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

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

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

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

почему-то мейнтейнеры дистрибутивов думают иначе

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

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

Но нет, зуд тщеславия

на самом деле, нет. ну, или не только он.

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

Хомячки от таких сказок только взвизгивают. Но на то оне и хомячки.

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

ОС, которые в народе называют «очень экзотическими»

Это точно не федора или дебиан.

кроме репозитория ОС нет и не может быть доступно ничего более

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

капец, ты болтун и диванный теоретик…. хотя, постойте-ка, у меня в заметках так и написано. Зачем я полез в дискуссию с тобой…

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

Согласиться мешает

пей таблетки. до встречи в игноре 😜

ПОСТОЙ, ТЫ НЕ НАПИСАЛ, КАКИЕ ИМЕННО ТАБЛЕТКИ!!((

Все наоборот. Надо поубирать те сложности, которые есть в квадратно-гнездовых ПМ, и будет и много версий сразу, и виртаулэнвы, и мир на земле.

Мейнтейнеры преследуют одну единственную цель - чтобы когда вы ставите Debian на парк из 1000 машин, разбросанных по стране вам нужно было только дать доступ к своему репу где лежит ISO. Потом apt install …. И всё, всё окружение готово к работе.

У вас нет проблемы, что вот там-то заблокирован доступ к github, что вася не обновлял свой npm месяц и теперь ему надо скачать 5 ГБ зависимостей, потому что оно устарело. Или оно при автоматическом CI/CD скачало какой-то реп а там изменения в АПИ.

При установке из репозитория вы имеете стабильную версию Х.У.Z, которая будет одинаковой на всем парке и которая не потребует перекачивать миллион пакетов на лимитном трафике. Плюс сюда же проблемы установки и работы через Air Gap.

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

При установке из репозитория вы имеете стабильную версию Х.У.Z

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

Каким образом мейнтейнер дистрибутива может выполнить эти условия для всех, даже с использованием и libastral.so - непонятно. В третий раз повторю пример с YaST в SUSE. Там где логично сделать этого системными пакетами оно сделано изначально системными пакетами и писалось с учётом этого и прекрасно работает в описанном вами сценарии.

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

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

Да и многие мейнтейнеры сдались, похоже. Мне приходилось тут собирать дистрибутив с нуля из его же пакетной базы src-пакетов. Так там очень плачевная ситуация - например, тебе нужно собрать какой-то системный пакет, в нем есть дока, к ней css «для красоты» -> css, например, минифицируется какой-то поделкой на жс, для сборки которой нужна нода, но её еще не собрать, как как она зависит от того системного компонента, с которого я начал повествование. :)

«сборка без документации» в том пакете не заложена. но это уже совсем другая история, которая напрямую не относится к вопросу из ОП.

который конкатенировал строки.

дополнял пробелами же ;)

Ещё раз повторюсь, современная веб-разработка (не только Ruby, но и Javascript, Python, Go, PHP, Elixir, Crystal и т.д.) невозможна без гибких возможностей разрешения, версионирования и обновления зависимостей. И это послужило причиной появления собственной инфраструктуры из репозиториев и пакетных менеджеров, т.к. традиционные пакетные менеджеры дистрибутивов работают в другой парадигме завязанной на релизы дистрибутива и срезы дистрибутивных репозиториев. Т.е. комьюнити данных языков взяли всю эту ответственность и расходы на себя.

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

а развивать свои пакетные менеджеры,

А теперь расскажите, как, по вашему мнению apt должен тянуть пакеты с npm?

По моему мнению он не должен этого делать.

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

При установке из репозитория вы имеете стабильную версию Х.У.Z, которая будет одинаковой на всем парке и которая не потребует перекачивать миллион пакетов на лимитном трафике.

Кто только будет её поддерживать вместе со всеми зависимостями? Авторы библиотек на такой сценарий не рассчитывают, они и линуксом то может не пользуются. Дубовый апт в свою очередь не расчитан на разгребание кучи версий одной библиотеки. Так что ментейнеры оказываются в интересном положении. Просто залить случайную версию тех же рельсов и забыть про них, такого и даром не надо. Но именно так и получается в дебиане.

Чисто теоретически, можно было бы заинтегрировать их (и прочих) друг с другом, чтобы пакет ставился каким-нибудь apt-npm install libjsfufel, виделся всякими там dpkg и апдейтился/удалялся бы по apt update/delete/purge. Только, во-первых, непонятно кому это надо и зачем, и во-вторых, понятно, что надорвались и забили бы уже здесь, даже до попыток работы со всякими многоверсионными установками и виртуальными окружениями.