Как собирать под федору пакеты на Rust?

Что-то как-то не помогло.

Ты же архитектуру обещал.

так вам не поможет, альфа. вы только критиковать умеете. вам представили рабочий дистр с означеным выше подходом к сборке, в том числе с оглядкой на специфики соответствующих языков в том числе d и rust ещё 3 года назад!

мне ваши потуги в федоре и с тем что вы вытворяете с dnf и анакондой - кажутся детским лепетом!

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

Но для этого надо написать немножечко больше текста чем у тебя там сейчас в README.

Напиши по-русски например, и выкати отдельным тредом.

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

Не надо писать код. Надо писать текст, который объясняет суть идеи.

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

Ну текст писать тут - станешь metaprog. Такие вещи надо или в переписке обсуждать, или… Здесь площадка не та. Или бабушка что-то не понимает?

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

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

А metaprog или не metaprog - это поживём увидим.

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

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

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

Для статьи надо не только копаться в вопросе, но иметь знания уровнем выше. Как показывает личная практика бабушки, вещи крайне редкие, под час невозможные. Здесь личности, которые разбираются в вопросах, вымерли. Бабушка помнит…

По Вашему вопросу, Альфа, бабушка не просто так вспомнила stack… Но, как Вы верно заметили, надо уметь в птичий язык с примесью английского и юмора, в вопрос, желательно прочесть пару статей, не вспоминать Cabal всуе и так далее. Бабушка считает, что те, кто умеет в это… Не будут этим заниматься.

Анон, да ты прямо жжешь! Жги! Жги ещё! Твой слог ночью радует наши сердца, греет души! Есть ещё среди нас ГЕНИИ!

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

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

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

А по факту очередной кухонный трёп.

не боги горшки обжигают. все люди и у всех свои запросы.

вы хотите получать вещи бесплатно. но свободный код и бесплатное пиво - это разные вещи.

дело в том, что я решил не идти путём rpm ещё в 2009 году.

а у вас проблемы и вы их не видите, да и не хотите видеть. больше проблем - больше работников и зарплат.

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

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

Эх, Альфа, Альфа... Упустила пацана.

Так там инструкция к сборке ghc начинается со слов: «чтобы собрать ghc, возьмите ghc..»

Так ведь стандартная практика: сначала качаешь бинарь ghc, а потом он собирает сам себя. Кстати, в убунте так же ставится stack:

sudo apt-get install haskell-stack
stack upgrade --binary-only
sudo apt-get purge haskell-stack
export PATH=$HOME/.local/bin:$PATH

Почитал, задумался. Это, стало быть, гента - дистр для красноглазия, да? А у Федоры, как я погляжу, все красиво.

Еще вариант: NixOS.

export PATH=$HOME/.local/bin:$PATH

Какой ужас. Там о no-exec home не слышали, да?

чтобы собрать ghc, возьмите ghc

Что-то вроде ghc-bootstrap то есть?

В gentoo, например, для сборки go нужен пакет go-bootstrap, но только если go в системе ещё нет. Для дальнейшего обновления этот bootstrap пакет не нужен.

Ещё забавно, опакечивать пакеты приложений, написанных на языке go, в том плане, что может быть порядка 100 зависимостей, которые выкачивают свои зависимости и в итоге получается ~400 мелких пакетиков, которые уже выкачивает emerge. Хорошо, что скачать он их может заранее и для непосредственной сборки интернет уже не нужен .

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

Здравый смысл мешает.

Ещё забавно, опакечивать пакеты приложений, написанных на языке go, в том плане, что может быть порядка 100 зависимостей, которые выкачивают свои зависимости и в итоге получается ~400 мелких пакетиков, которые уже выкачивает emerge. Хорошо, что скачать он их может заранее и для непосредственной сборки интернет уже не нужен .

Я правильно понимаю, что go-приложения это ад для администратора контейнеров?

менеджеры версий пакетов для go давно есть

Здравый смысл мешает.

а точнее - его отсутствие

Не знаю о контейнерах. Я описал на примере ebuild в генту для gogs. В генту для манипуляций с подобными вещами есть eclass, который своими вызовами обеспечивает скачивание того, что перечисленно в определённой переменной и дальнейшую сборку этого всего в изолированном от сети sandbox.

Но тот же lazygit на go ничего не тащит.

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

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

Хотя кому я это объясняю.

ШУЕ!

дядя, ты не поехал кукухой, как для 2005 года.

повторяю 3й (или 4? - уже со счёта сбился) раз для тугодумов:

1. качаешь пакеты
2. патчишь
3. выкладываешь в свою репу
4. юзаешь нативный инструмент, а не велосипедишь в dnf/apt/etc

я не понимаю.. куда проще объяснять? тебе самому не кажется странным то что ты озвучил про количество пакетов для go? вы так никогда самостоятельно не перенесёте всю экосистему с каждым пакетом к сабе под именем golang-тратата.rpm - это нонсенс.

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

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

3. выкладываешь в свою репу

Это ещё нафейхоа? Какую ещё, едрить, репу?

Я озвучил не количество пакетов для go, а количество tarball’ов, которое выкачивается для gogs. Я не собираюсь переносить всю экосистему. Текущий подход сборки go-пакетов в gentoo подразумевает, учитывая, что все эти go-зависимости всё равно линкуются статически, сборку внутри sandbox. Опакечивать вот всё-всё при этом не нужно.

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

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

Какую ещё, едрить, репу

ну как с вами разговаривать? лол. чел не в теме, что в go / pip / cargo можно организовывать свою приоретизированную репу для пакетов.. специалистзды..

В общем, развлекайся: https://gitweb.gentoo.org/repo/proj/guru.git/plain/www-apps/gogs/gogs-0.12.3.ebuild

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

Зачем мне в рамках дистрибутива какие-то отдельные языкоспецифичные репы для пакетов делать?

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

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

у меня нет слов.. ты ломанулся не в ту степь.. я вот ввожу dnf search golang: она мне выводит дохрилион пактов, которые типа-натизивизированы в экосистему dnf - но вопрос: «нафейхуя» все вот эти golang-*? пользователь будет ими пользоваться?

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

спрашиваю 6й раз.

пакет-зависимость из go - с ошибкой? - регестрируешь его в своей приоретизированной репе и говоришь go get качать из неё перед сборкой. и он скачает.

вот этими golang- и python2- python3- пакетами - вы загаживаете системы..

блин.. мне надоело эти простые истины доводить.. делайте как хотите..

Но dnf тоже из инета качает. Какая разница?

спрашиваю 6й раз

Отвечаю а 12й: для воспроизводимости сборки.

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

Он делает это заранее, перед запуском скрипта сборки.

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

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

Кэш недетерминистичен, это в лучшем случае «так получилось».

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

ментейнер собрал пакет - работает; через полчаса собрал - не работает

ещё раз:

1. и в Go и в Rust и в D - есть версионирование. они уже не качают собирают и не собирают что попало, а то что прописано в списке версий
2. если ты поднимаешь свою репу, ты можешь ограничить и фиксировать версии в ней

Кэш недетерминистичен

ещё один.. откуда вы только берётесь

ребят.. я вам последний раз пишу: RTFM по go get / cargo / dub

Писал DNF ужасным говнокодом на питоне.

Карго делает то же самое. Он сначала качает зависимости, если их ещё нет в кеше, а затем собирает.

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

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

Полностью согласен.

Ещё раз - мне не нужна третья сущность в виде отдельной репы для сборки пакета средствами дистрибутива.

А вот писали бы всё на няшной сишечке, таких проблем бы и не возникало!

Запуск карго осуществляется запуском чего? Кэш карго является кэшем дистрибутива и управляется им?

Да, судя по всему, как и в случае с go, в генту для rust аналогично в соответствующем eclass вызываются команды пакетного менеджера языка для предварительного выкачивания и последующим подсовыванием этих пакетов в кэш cargo внутри sandbox. Но мне не кажется, что подобный подход делает кого-то счастливым, т.к. он используется от безысходности.

И выглядит оно так: https://raw.githubusercontent.com/gentoo/gentoo/master/eclass/cargo.eclass

А вот писали бы всё на няшной сишечке, таких проблем бы и не возникало!

во-во. или на vala, хотя бы.