LINUX.ORG.RU

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

 , ,


0

4

Ну в принципе, мне все в packaging guidelines понятно, да и спек на пакет написан до меня. Но когда я пробую натравить на него rpmbuild, он ругается на меня, что у меня нет множества пакетов типа

(crate(some-library/default) >= 1.0.0 with crate(some-library/default) < 2.0.0)

dnf таких выражений не понимает (ни полностью, ни crate(some-library/default)). Пакеты типа rust-some-library-devel+default.noarch.fc32.rpm существуют, даже в репозитории есть, но только если знаешь точный URL. dnf их не устанавливает. Более того, dnf build-dep бодро рапортует, что все зависимости установлены (на самом деле нет).

Федоровцы, ау, как вы собираете растопакеты?

★★★★★

Ответ на: комментарий от alpha

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

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

shimon ★★★★★ ()
Ответ на: комментарий от shimon

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

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

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

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

im-0 ()
Ответ на: комментарий от Crocodoom

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

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

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

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

im-0 ()
Последнее исправление: im-0 (всего исправлений: 1)
Ответ на: комментарий от alpha

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

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

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

shimon ★★★★★ ()
Ответ на: комментарий от shimon

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от shimon

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

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

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

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

alpha ★★★★★ ()

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

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

It’s turtles all the way down.

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

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

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

shimon ★★★★★ ()
Ответ на: комментарий от alpha

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

shimon ★★★★★ ()

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

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

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

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

shimon ★★★★★ ()
Ответ на: комментарий от shimon

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от shimon

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

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

alpha ★★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от shimon

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

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

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

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

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

alpha ★★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

anonymous ()

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

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

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

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

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от im-0

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от alpha

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

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

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

BaBa_Galya ()
Ответ на: комментарий от alpha

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

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

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

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

anonymous ()
Ответ на: комментарий от i-rinat

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

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

BaBa_Galya ()
Ответ на: комментарий от i-rinat

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

BaBa_Galya ()