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

[user]maxcom[/user], разжалуйте, пожалуйста [user]grem[/user]: на мой взгляд, злостный отказ разбираться в предметной области - заявка на увольнение в запас.

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

Говоря о нашей любимой генте, там несколько месяцев нельзя было поставить Qt Creator, ибо он зависел от ~amd64 Qt, а один из модулей был вообще masked. Ну а старую версию они, по доброте душевной, тоже выпилили. Это пофиксили буквально неделю назад.

Это такое пробивание дна в плане юзабилити, что я даже не знаю.

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

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

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

я уже думал над этой проблемой.

на самом деле решение лежит на поверхности: для C/C++ нужен такойхе сорц-менеджер как у Go / Rust /D - и дело в шляпе.

системные и несистемные

что необходимо для сборки gcc / go /rust / x11 / wayland / systemd / docker и gnome - всё системное

и gnome

тут половина всего существующего опенсорса будет в зависимостях, «несистемных» мало останется

ну ок.. в принципе то и twm достаточно для работы с пристрастием

Давай, расскажи мне про опакечивание софта.

я приводил выше ссылку. жуй что альфа недожевала.

Насчёт флатпаков в 10ке не знаю, я её только на ноуте тыкал чуть. Но вот куча софта собранного под виндоус тащит все поголовно либы с собой. Исключение обычно составляет c++ redistributable и .net. Из-за этого, софтина весит … много весит. Зато не зависит от системных либ и не конфликтует с софтом, который хочет другую версию либы. Обычный bundled. Так некоторые и в Линукс поставляют софт.

Залез в appstore и глянул размер приложения сбербанка - 400 мб для скачивания.

Qt Creator зависел от ~amd64 Qt

Так он и сам был ~amd64. Но обновляет ментейнер его редко. У тебя ж шустрый проц - давно добавил бы отправил пул реквест на добавление себя в ментейнеры. Тем более, что текущему ebuild нужно сделать bump и добавить поддержку >=llvm-10.0.1. У меня этот light ide собирается часа 2.

Я хотел для guru установку из .run запилить, но оффлайновый инсталлятор требует ввода аккаунта для продолжения установки. То есть даже выкачиванием не отделаешься.

Вот что на gentoo действительно боль, судя по состоянию инфраструктуры, - поддержка java. Даже ментейнеры проекта не скрывают, что состояние у него «пациент скорее мертв, чем жив».

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

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

Мне, как разрабу, должно быть вообще по барабану что там в дистре за версии. Я написал в конфиге что мне нужен Qt 4.8.2, и где его будет брать ПМ - мне без разницы.

Насколько я знаю, подобное допускает разве что nix.

Поэтому распространять проприетарщину/бинари в лине фактически невозможно.

По сути ядро.

Идеальный ПМ должен поддерживать множество версий одного и того же пакета в системе. Что и делает cargo.

Ну почему? Вон xnviewmp вместе с либами qt поставляется сразу - распаковываешь и пользуешься.

Разве не статически в итоге при сборке всё линкуется?

Мне, как разрабу, должно быть вообще по барабану что там в дистре за версии. Я написал в конфиге что мне нужен Qt 4.8.2, и где его будет брать ПМ - мне без разницы.

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

По сути ядро.

что значит «по сути ядро»

Но вот куча софта собранного под виндоус тащит все поголовно либы с собой.

Не все, ибо winapi. На лине Qt зависит от fontconfig, freetype, harfbuzz и прочих. Тащить их с собой - бред.

Из-за этого, софтина весит … много весит.

Это никого не волнует.

Вот что на gentoo действительно боль, судя по состоянию инфраструктуры, - поддержка java.

Но это не мешает им поддерживать 100500 пакетов питона и хаскеля.

Сама идея тащить всё в дистр - тупик.

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

Обратная совместимость - миф. И я не про Qt.

А если моя прога зависит от новой версии freetype, то что, я должен ждать пока мейнтейнеры дистра Х пошевелятся и обновят её? Да я быстрее в статику соберу и готово. Что я и делаю.

Или наоборот, в новой версии что-то наломали, и я хочу ограничить макс. версию. Опять нельзя.

Что я могу сказать: cargo, cargo, cargo.

Ага, если бы. Я за последние лет 8 видел такие приколы с распространением проприетарщины на лине, что лучше сразу вдоль.

Что характерно, макось не лучше.

Пусть патчат сами, если им так горит.

Сколько боли было с openssl, который постоянно ломает api и даже именование либ.

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

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

У меня так как-то на прошлой работе приходил devops один, и говорит: слушай, я тут смотрю на всякие наши go-микросервисы, и с ними так сложно и тяжело. А что если мы сделаем такой универсальный формат для их описания, чтобы там можно было указать версии, и зависимости, и совместимость, и как их запускать, и post-install и post-uninstall… И потом поместим этот набор метаданных в отдельный реестр, и сделаем такой инструмент который будет с помощью этих метаданных устанавливать и запускать сервисы..

И я так да, действительно, а что если вдруг неожиданно мы изобретем такой формат…

А если моя прога зависит от новой версии freetype, то что, я должен ждать пока мейнтейнеры дистра Х пошевелятся и обновят её?

можешь запилить свой кастомный репозиторий для этого дистра, собрать свой пакет с новой версией razrfalcon-freetype-xx.yy и пусть пользователь ставит и обновляет из этого репозитория

И так для 100500 дистров? Бред.

начинает переизобретать механизмы работы стандартных дистрибутивов

Это вы про App Store и MS Store? Или про 1%?

Сколько боли было с openssl, который постоянно ломает api и даже именование либ.

перейти на новый API - максимум день работы

почему 100500, 3-5 самых популярных, остальные пусть сами стараются, или за отдельную плату

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

1. И так всё работало.
2. Что делать со старыми бинарями?

Почему ты считаешь, что самостоятельно собирать все зависимости (а их ещё надо периодически обновлять) менее трудозатратно, чем по возможности пользоваться готовыми из репозиториев? На винде и маке они тоже есть, в виде mingw, homebrew и macports

самостоятельно собирать все зависимости

Алё, сишка умерла. В нормальных ЯП есть нормальные ПМ, которые делают всё за меня.

На винде и маке они тоже есть, в виде mingw, homebrew и macports

Смишно.

Надо держаться в струе прогресса! Старые бинари - для старых пердунов, новые бинари - для модных хипстеров со смузи! Ну и кто будет за подписку для твоей проприетарщины платить, если старые бинари и так работает?

В нормальных ЯП есть нормальные ПМ, которые делают всё за меня.

Покажи мне тот же Qt, написанный «нормальным ЯП и собранный нормальным ПМ» за тебя

mingw, homebrew и macports

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

фиксированную версию либы собрав её с нужными флагами

нужность этого преувеличена

компилятор - чем собраны либы, тем и программу собираем, а как ещё

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

Идея состоит в том, что имея в наличии комп и локальное зеркало репозитория, всё можно пересобрать без доступа к внешним сетям. И никакой внезапно пропавший leftpad не сможет это поломать — все нужные зависимости всегда есть. Если вдруг нет, это баг типа «Fails to build from source».

Cargo это всё умеет.

нужность этого преувеличена

Попробуйте писать софт сложнее hello world.

чем собраны либы, тем и программу собираем, а как ещё

Ага, только в mingw у нас gcc, а свою прогу я через msvc собираю. Удачи.

Попробуйте писать софт сложнее hello world.

пробовал, всё работает

Ага, только в mingw у нас gcc, а свою прогу я через msvc собираю. Удачи.

Нет никакой необходимости собирать прогу через msvc

Только все проблемы линя растут из-за убожества С/С++, с отсутствием единого ПМ, динамической линковой и прочей ерундой.

Что именно умеет?

пробовал, всё работает

На локалхосте? Поверю.

Нет никакой необходимости собирать прогу через msvc

Лул. Саархитку номер 2.

Кастомные репозитории, source vendoring и накладывание патчей.

Лул. Саархитку номер 2

Не всем не хватает квалификации писать кроссплатформенный код! Некоторые и код, конпеляющийся в gcc писать могут!

Не все, ибо winapi

Qt, gtk3, wxGTK, …- любой сторонний тулкит.

Но в виндоус то fontconfig, harfbuzz и кампания отсутствует. И тащат ведь. Зато есть плюс - можно пользоваться очень старой версией софтины.

Это никого не волнует.

notepad++ ~3.5 мб

Kate ~60..80 мб
Gimp ~220 мб
Qtcreator - от 2 до 4 гб

Меня волнует.

Но это не мешает им поддерживать 100500 пакетов питона и хаскеля.

Не мешает, потому что они сами, видимо, этим пользуются.

Тащить всё действительно странно. Но иначе пока сложно обеспечить целостность системы. Может где-то и есть ПМ, который управляет другими (pip, cargo, go, nmp, …) и сам знает что чем установлено в систему.

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

Ну вот Skia и Хром не собираются через mingw. Какие нехорошие бракоделы.

Я не понимаю, что ты этим всем хочешь сказать. Это как-то решает проблему пересборки софта из исходников без доступа к интернету? Мне интересно, как ты себе процесс представляешь.

И тащат ведь.

Тащить fontconfig и freetype в винду может только говнокод уровня GTK.

notepad++ ~3.5 мб

Ну так winapi же. В лине такой трюк не прокатит, о чём и речь.

Qtcreator - от 2 до 4 гб

500MB. Из которых 250MB - это clang.

Но подход контейнеризации всего и вся тоже тупик.

Норм. Других вариантов пока нет. Разве что wasm.