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

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ это ты уже читал я так понимаю?

Там действительно есть какая-то подстава с buildroot, но я не в теме.

Спрашивать i_gnatenko_brain или Rust SIG.

Да, читал, только вот готовые спеки не собираются. (Да вот хоть тот же firefox, чтобы далеко не ходить.)

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

Посмотри #19 вот тут:

https://msehnout.fedorapeople.org/rust-fedora.pdf

Там какая-то растовая магия добавляется.

Дока правда от 2017 года, поэтому надо проверять, актуальна ли она.

Да, читал, только вот готовые спеки не собираются. (Да вот хоть тот же firefox, чтобы далеко не ходить.)

Я тоже не знаю как именно работает сборка исходников на расте в федоре, но могу посоветовать попробовать mock, который создаёт контейнер/чрут с чистой сборочной средой. Вдруг там нужная магия сработает. Насколько я понимаю, koji, который автоматически собирает пакеты для официальных репозиториев (и не только), внутри также использует mock.

mock --rebuild path/to/your.src.rpm

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

Наверное, глупый вопрос, но зачем эта возня с dnf, если у раста есть cargo?

Наверное, глупый вопрос, но зачем эта возня с dnf, если у раста есть cargo?

• Обновлять софт на расте вместе с остальной системой, стандартным способом.
• Не собирать тяжёлый софт заново на каждой машине, если их много.
• Автоматически ставить нужные зависимости, если они не на расте написаны. Тут cargo в лучшем случае просто ничего не сможет собрать, в худшем втихую налинкует полурабочих бинарных либ сомнительного происхождения.

Может что-то ещё.

В общем, ответ примерно тот же, что и на «зачем в репозиториях питонопакеты, если есть pip».

Это шизофрения как с Firefox в дебиан, они опакечивают расширения, естественно все там протухшее.

Это я тоже читал. Но кейс-то собственно в том, что:

нужен, допустим, пакет, который дает crate(proc-macro2/default). Таковым является rust-proc-macro2+default-devel.noarch. Я его не могу найти через dnf search или поставить через dnf install (справедливости ради, здесь я его тоже не вижу). Но при этом я его вижу вот здесь, то есть Koji его собирает, но почему-то ни в какой репозиторий результат не идет.

В этот момент мне хочется кричать «да вы там обалдели совсем» или что-нибудь нечленораздельное. Впрочем, мне не впервой находить пакеты, которые собираются Koji, потому что Koji, судя по всему — исторически сложившаяся пакетопомойка, где пакеты собираются даже без прописанных зависимостей просто потому, что какая-то версия на билдхосте завалялась чудом. А в COPR, где сборка идет специально с чистого листа, это не работает (если что, исправления были высланы и приняты даже). Но то, что творится с пакетами на Rust — это явление слишком большое и слишком системное, тут одним-двумя пуллреквестами не обойдется.

В этот момент мне хочется кричать «да вы там обалдели совсем» или что-нибудь нечленораздельное.

Ты не одинок. В чатике #fedora-rpm-ru:matrix.org раз в пару месяцев дым коромыслом по этой теме.

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

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

Нет, там используется «чистое» окружение. Просто конфигурация у него сильно сложнее чем - взял текущую репу и пересобрал. Там семь слоев с inheritance и всякие Autogenerated BuildRequires недавно добавили, поэтому локальное окружение может отличаться.

Кстати сказать если прост scratch build в koji делать - тоже не собирается?

И в общем надо писать/искать баги в COPR как минимум.

Из горящего танка:

— чтобы собрать rust-quote, нужен rust-rustversion — для сборки rust-rustversion нужен rust-quote

It’s turtles all the way down.

От этих двух пакетиков прямо или непрямо зависит пол экосистемы раста, so there’s that.

Я нашел нужный мне пакет на COPR (и так пришлось утащить к себе и пересобрать), но автор спека махнул рукой на канон и тупо собирает с помощью cargo (нужно включать доступ в интернеты для сборки).

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

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

На такой же вопрос, как у меня, не отвечает вот этот тред:

https://lists.fedoraproject.org/archives/list/rust@lists.fedoraproject.org/thread/DJFNZB3ALER2A75AL2NNJTEDWLHSL4RL/

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

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

— чтобы собрать rust-quote, нужен rust-rustversion — для сборки rust-rustversion нужен rust-quote

Таких пакетов немало и вне раста. Есть там такие фишечки и у ruby и python.

У python кажется есть bootstrap flag, который отрубает половину спека и собирает маленький кусочек сначала. Потом поверх ты собираешь библиотеку, а потом ещё раз уже нормальный python без флага.

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

Да, примерно так. К сожалению он сбежал из Red Hat на волю, так что теперь реализовать этот план стало чуточку сложнее.

А чем он занимался в редхате?

Ну подробности надо у него спрашивать.

Вроде как dnf, ну и всем до чего дотянулся.

как с Go, так и с Rust, я через DNF устанавливаю только сами компиляторы и генераторы документации.

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

— чтобы собрать rust-quote, нужен rust-rustversion — для сборки rust-rustversion нужен rust-quote

Я когда работала суппортером в хостере, поспорила с коллегой что могу собрать haskell-интерпретатор на shared-хостинге.

А shared-хостинг - это когда без прав рута и общий апач, и всё это на FreeBSD.

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

В итоге собрала как-то. Правда сейчас вот никак не вспомню как именно.

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

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

Это ручной вариант аля pip говно. Норм если на месте собрать что-то и ад и позор если нужна автоматизация. Федорка (как и остальные дистры) имеет механизмы билда пакетов на системном уровне без засирания и ручного ковырягания. А некоторые как в старт посте положили болт на экосистему каким то чудом пропихнув туда свою отсебятину которая если и работает то с бубном мотив ударов по которому знает только публикатор

«очень интересное» мнение.

но мне сдаётся, что вы просто не умеете готовить ни pip, ни go get/ go mod download, ни cargo

я вообще считаю, что попытка dnf перебирать на себя функции нативных геттеров go /rust / python/ d - плохая идея. да и анаконду и сам dnf следовало бы переписать на vala

Не ты меня не понял. В дистрибутивах есть dev и source пакеты и именно ими рулит система для воспроизводимой сборки того что есть в репозитории. Ты же не предлагаешь в этих пакетах совать скрипты которые будут дёргать pip/cargo и иже с ними которые будут выкачивать сырцы? Нет батенька, есть локальное использование пакетов языков, оно годно когда прямо здесь и сейчас, а есть билд система дистрибутива в которой сборка не тяп лая главное что-бы собралось, а воспроизводимая отслеживаемая и контролируемая сборка как основа самого дистрибутива. В старт посте боль про то что в репах есть исходники для сборки в виде зависимостей которые почему то игнорируют правила и политики сборки. Пипов и каргов может быть много, а вот пакетная база и форматы у дистрибутива одни и если что-то есть в дистре то это должно быть в его родном виде, а не в виде как хочу так и ворочу. Ещё раз повторю пипы и карги это говно для автоматизации ибо всё на честном слове. В чисто разработке ляпота, но никак не для билд системы дистрибутива.

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

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

и pip и go get / go mod (и в cargo и в dub тоже есть, наверное) - поддерживают создание своих репозиториев с сорцами - контролируйте свои копии и получите предсказуемость, о которой говорите, и не придётся перенимать функционал из родных инструментов.

похоже ещё один гентист понял, кто хозяин на этом поле :)

я вообще считаю, что попытка dnf перебирать на себя функции нативных геттеров

Лол что? Всё наоборот это эти языки расширили себя до wgetтеров. Ты понимаешь что такое дистрибутивы? Ты будамешь федора/дебиан/убунту/иное просто так из апстрима качают исходники собирают как попало и всё? Нет уж, сначала берётся апстрим версия, затем исходник перелопачиватся и формируется пакет исходного кода затем этот пакет проходит черед билд систему и рекеры, по нему поднимаются багтрекеры затем исправления их в виде патчей добавляются к пакету исходного кода, при этом патчи отправляются в апстрим примут там их или нет не ясно и не ясно когда если когда либо вообще. Но пакет есть и нужно обеспечивать его работоспособность и тд и тп и только по итогу ещё не одного шага взрослый пакет с подготовленным исходным кодом и патчами обеспечивающими работоспособность пройдя через полностью автоматическую билд систему и CI тесты авоматические попадает в бинарную репу где ты свои менеджером пакетов можешь им рулить как угодно собирать/пересобирать узнавать где как что от чего зависит и прочее прочее. То есть получить отлаженный кусок кода или бинарника. А не то что как повезёт, вчера работало завтра в апстриме поломали и досвидания.

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

Это работает до тех пор пока твой проект не выходит за рамки одного языка программирования.

А потом начинаются всякие нехорошие эффекты когда разработчик не может вылезти за пределы языка и его экосистемы и начинает микроскопом забивать гвозди. Например для настройки cron-задачи на сервере запускать там JVM с tomcat, в котором cron реализовывать как spring-приложение, ну и всякие подобные завихрения.

Либо всякие попытки скрестить ужа с ежом домашними средствами. Что тоже не весело.

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

повторю этот вопрос: Как собирать под федору пакеты на Rust? (комментарий) - что мешает поднять свои собственные репы с исходниками и не пытаться втянуть в dnf то, что отлаживается годами в нативных инструментах?

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

Это работает до тех пор пока твой проект не выходит за рамки одного языка программирования.

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

Ещё раз говорю ты говоришь dnf есть пакет foo-bar? Он тебе говорит да есть! Ты ему а нук сбилди мне его. Он тебе сломанны зависимости, ты такой смотришь, а в зависимостях каша. Ты говоришь ему найди bar-foo-dev , а он тебе ПНХ! И всё. Причём тут левые пакеты, разговор про пакеты из пакетной базы дистрибутива а пакеты из дитсрибутива обязаны быть восроизводимыми ибо сборка не под 1 архитектуру например. **Всё должно быть опакечено, а не притянуто пипами и прочим хрен пойми откуда.

я не буду продолжать тут вразумительные беседы.. тяните и жируйте dnf дальше.

Нахрен мне надо я apt/dpkg использую ))) Но суть то та же python deb пакет != python pip «пакет». А содержимое одно и тоже только первое встроено в инфраструктуру дистрибутива, а второе само по себе из апстрима.

Светофоры задолбали1!

решаются нормальной оргнизацией экосистемы сборки пакетов

Именно, только она не должна быть зависимой от языка. Что собственно и делают в дистрибутивах.

Понятно что для того чтобы это работало более менее гладко надо оторвать руки некоторым переизобретателям уникальных пакетных менеджеров (и да, это про rvm, nvm, go и т.п.) не желающим соблюдать хоть какие-то общие стандарты. И тогда дистрибутивам не пришлось бы заниматься reverse-engineering-ом и распаковкой упакованного. Но что есть то есть, приходится с этим разбираться.

Ну, многие исходники содержат каталог debian или/и rpm и в них вся иформация для опакечивания исходника сразу из апстрима. rustтеры/goшники/пинеры эту практику игнорируют свято считая что их исходный код будет поставляться исключительно в экосистеме языка, вот так и сгнили в безысвестности и утанули в мусоре сотни хороших пакетов эталонного мысамипосебе я про npm. Хотя те кто удостужились понять что дистрибутивы есть не просто так сделали каталожики для формирования пакетиков и пракрастно себе живут в репах дитсрибутивов доступны по щелчку пальца для пользователя/разработчика повторяемы,предсказуемы,с багтрекером патчами и поддержкой.

Мне кстати вот только что дали почитать

https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches

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

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

И из этого предложения следует, что ты наверное под релизную федору собираешь, а надо собирать под rawhide.

зачем эта возня с dnf, если у раста есть cargo?

Чтобы можно было собирать без доступа к интернету.

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

как же правильно я сделал, что решил не использовать опыт dnf и rpm в своём решении. и сдаётся мне, что с такими спецами как вы, fedora ждёт не очень светлое будущее.

Собственно типичный пример: установка pip-ом lxml, которая тут же требует сишных devel-библиотек и компилятора.

Хотел скрипт из пяти строчек запустить, а поставил полсистемы средств разработки. И никто не гарантирует что твоим системным gcc твоя несистемная python-библиотека вообще соберётся. Или какой openssl и какую именно криптографию она будет при этом использовать.

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

Не собирать тяжёлый софт заново на каждой машине, если их много

Как я понял, в Rust на стабильный ABI окончательно забили где-то год назад, так что вряд ли в ближайшем будущем получится использовать предкомпилированные библиотеки. По крайней мере, в Debian растовые dev-пакеты сейчас содержат в себе только исходники и мета-информацию для cargo. Наверняка и в других дистрибутивах так же, ведь сборка всего из исходников это ограничение компилятора.

Так там инструкция к сборке ghc начинается со слов: «чтобы собрать ghc, возьмите ghc..» В итоге собрала как-то. Правда сейчас вот никак не вспомню как именно.

Что ты, аки маленькая!.. Бабушка тебе скажет, как: берёшь бинарник (чаще всего, чтобы без заморочек Centos.rpm старый-старый), в tmp распаковать, скриптом пути дать, исходники свежей версии ghc стянуть, нажать build, ждать, запаковать в пакет на своей системе, установить, tmp почистить.

И что? Штангисты, деточка, уже порешали. Всё теперь за них, родимых, stack делает.

что решил не использовать опыт dnf и rpm в своём решении

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

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

они и не должны знать это.

просто нужно чтобы менеджеру сборки были известны необходимые зависимости, для сборки того или иного пакета. и если таковыми зависимостями являются пакеты из go/python/d/rust - подкачивать эти зависимости из своего репозитория с пропатчеными (если нужно) сорцами, используя нативный инструмент, а не перетаскивать функционал в менеджер сборки.

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

Наверняка и в других дистрибутивах так же

Не везде. Но, скажем так, что-то собрать квест на половину часика-час, чтобы запустить build. Бабушке захотелось alacritty в своё время. Квест был интересен. Попробованы binary deb и source based. Легче оказалось в s/b. В бинарных - это АД.

ради бога, жуй https://github.com/AnimusPEXUS/aipsetup

Не везде.

В каком-то дистрибутиве используют предсобранные Rust-пакеты? В каком? Хочу на это глянуть.

Так ты приноси статьи, ссылки, код - будем разбираться. Что руками-то машешь?

Чтобы запустился build, нужны зависимости. По cargo - что в build было прописано, то и собирал, подтягивая с инета (как и с Haskell). Чтобы что-то было предсобрано? Да пакетный менеджер этим рулил? Сама не видала и боюсь себе представить. У них, Растовцев, ИМХО там полная неразбериха. Как ты писал, милок, ломают всё, что могут. Мне было бы жаль тех мейнтейнеров…