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

Если есть vendoring пакет - инет не нужен.

xnviewmp, aftershot, skype, rawtherapee работали не хуже непроприетарщины и 5..12 лет назад.

Пока что я вижу, что ты не понимаешь, о чём идёт речь.

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

Примерно так.

зоопарком дистров пусть кто-то другой возится.

В итоге никто не возится?

Это на смартфонах разработчик сам собрал, сам запихнул в магазин

дело не столько в платформе сколько в способах использования. App в AppStore - это черный ящик. Он может быть сделан из open source кода, но на самом деле ни разу не открыт с точки зрения администратора системы или пользователя. Такие apps можно продавать, но из них нельзя делать например свой инфраструктуру, создавать какие-то собственные проекты и т.п.

Если с приложением из дистрибутива я могу работать, например сделать к нему шаблон для распространения среди 100500 юзеров которых поддерживает мой IT-департамент, то с app так нельзя. Это чисто индивидуальное приложение для покупателя-одиночки.

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

Можно пример проекта, где cargo умеет собирать отдельные куски проекта написанные на C, C++, Fortran, Python и упаковывать это в один пакет?

говнокод уровня GTK.

На это я могу ответить только «сперва добейся».

И никакой внезапно пропавший leftpad не сможет это поломать — все нужные зависимости всегда есть.

Я про это.

И поэтому пол лора забито неработающим skype, ага.

Да мне без разницы. Кому надо - собирают сами. Благо дело с cargo это не проблема.

А если речь конкретно про resvg, то debian вроде пытается. Но я не слежу. У меня всё так активно меняется, что им не успеть.

Про питон не знаю, но зависимости на С/С++ - норма.

Где?

https://www.linux.org.ru/search.jsp?q=Skype&range=TOPICS&interval=ALL&user=&_usertopic=on&sort=DATE&section=

https://www.linux.org.ru/search.jsp?q=%D0%A1%D0%BA%D0%B0%D0%B9%D0%BF&range=TOPICS&interval=ALL&user=&_usertopic=on&sort=DATE&section=

Вторая ссылка: Skype + Centos 7.4 = F%$# и не работает

Пытался.

Это какая-то писанина «в стол» получается. Я с таким проектом на месте ментейнеров тоже не стал бы связываться.

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

Это какая-то писанина «в стол» получается.

Вы про проблемы одного процента? Большинство разрабов это не волнует.

Я про проблему разработчиков пишущих «в стол» связанную с тем, что и 99% тех, кого он мог бы заинтересовать, их код не нужен в итоге из-за подхода самих разработчиков к своему проекту.

99% - это линуксоиды? Ну так себе аналитика. Моим софтом вполне себе пользуются.

Я про это.

А я про всю цепочку в целом.

Вот здесь докладчик в красках расписывает сходные идеи: https://www.youtube.com/watch?v=fnELtqE6mMM. Доклад короткий, 16 минут всего.

Допустим, что они. Если тебя устраивает их незаинтересованность, то и обсуждать проблему сборки rust-проектов не стоит.

Речь изначально шла про ПМ в целом.

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

Только вот не надо опять про то, что «cargo - НЯ!», а всё остальное «не нужно».

каждый дистрибутив пытается решить эту проблему как может в рамках своей системы сборки

В этом и проблема. Сам подход тупиковый.

И нет, карго не альтернатива.

Идеальный ПМ - это:

cd ~/my-app
super-pm run

В результате получаем готовый пакет/бинарь который не зависит от ОС. И это должно работать на любой ОС.

Сейчас, поставить прогу/либу не из репозитория или другой версии фактически нереально.

Сейчас, поставить прогу/либу не из репозитория или другой версии фактически нереально.

С прогой обычно проще - собрал в home и там же оставил, либо закинул в opt. Я так обычно и делаю прежде чем лезть опакечивать. Хотя бы узнаю, запускается ли она вообще и как работает.

А потом системная либа обновилась и всё сломалось.

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

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

В федоре идея такая, что опакечены сырцы библиотеки (они noarch), а при сборке приложения cargo собирает именно из них (а не тащит из crates.io).

Но при этом они что-то намудрили, и теперь пакеты с крейтами доступны на раз только в rawhide, почему — внятного ответа не существует (и поэтому в 34 их вроде возвратят обратно).

Как собирать растоприложения для релизной федоры? Да непонятно как, особенно же когда там циклические зависимости есть, а сразу их не видно (бо Build-Depends динамические).

Некто alebastr собирает себе sway и разные штуки вокруг него, наплевав на официальный процесс, там в спеке тупо cargo отрабатывает, тащит либы из интернетов. (Например, нужный мне greetd на расте написан, так он у него так и собирается. Неканонічно, но работает, я не ропщу.)

Но при этом они что-то намудрили, и теперь пакеты с крейтами доступны на раз только в rawhide, почему — внятного ответа не существует

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

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

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

Вот теперь этот Fedora 34 Change должен немножко ситуацию исправить. Но проблема с поддержкой остается. Банально нужны люди которые будут эти библиотеки поддерживать после релиза.

В федоре идея такая, что опакечены сырцы библиотеки

Вот такую штуку надо бы запилить в NixOS. Вроде бы там пока карга с инета тянет.

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

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

дело не столько в платформе сколько в способах использования. App в AppStore - это черный ящик. Он может быть сделан из open source кода, но на самом деле ни разу не открыт с точки зрения администратора системы или пользователя.

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

Подожжите-подожжите, этот ваш раст что, в динамические библиотеки не умеет?

линковка и компиляция - это разные плоскости существования. естественно проги на Rust могут быть разбиты на либы

в динамические библиотеки не умеет?

В принципе умеет, только АПИ будет сишное там (для того чтоб растовую сошку к си линковать или наоборот). Дженерики и макросы так не работают

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

Один ты ниасилил. Что толку от крутой программы которая гвоздями прибита к версии библиотеки по желанию твоей левой пятки?

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

И ты вот так лягко и непренуждённо шлёшь всё это лесом. Опирайся не на цифарки библиотек, а на API изменения, порой в мажорных версиях несовместимых тупо 1 функцию удалили и одну добавили, жопой пошевелить и реализовать deprecated функцию на новой и наоборот не трудно, да это не красиво, но и мир не идеален. C libjansson такая вот хрень у меня была и ничё.

Вот теперь этот Fedora 34 Change должен немножко ситуацию исправить. Но проблема с поддержкой остается. Банально нужны люди которые будут эти библиотеки поддерживать после релиза.

Я бы сказал, даже вот хрен с ней с поддержкой. Хотелось бы из спека, скажем, на ripgrep, собрать точно такой же ripgrep, как тот, что я установил из репозитория. Зачем? Ну, прихоть такая. Что-то новое пришло если не в 33-ю федору, то в rawhide, а я хочу это у себя сегодня-завтра. У меня на машинах гном и кде из rawhide вон стоят.

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

И к вопросу о переизобретении колес: ведь вот именно такие истории соблазняют людей изобретать управление пакетами заново, потому что на RPM/deb у них образуется слепое пятно и фобия. Тут люди говорят, что всякие расты и го — это будущее, Java тоже не последний игрок, но вот опакетить это по-человечески — сизифов труд, и еще при этом с дичайшим сопротивлением со стороны прекраснодушных идеалистов, которым всегда все не так, но как надо — ни объяснить, ни продемонстрировать они не могут.

Люди в сердцах махают рукой и решают вместо борьбы с мельницами собрать кусок слаки в контейнере. Так спокойней. Пока в OpenSSL или zlib не найдут очередную дырку.

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

Вот такую штуку надо бы запилить в NixOS. Вроде бы там пока карга с инета тянет.

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

Ну ты же понимаешь что я с тобой не спорю.

И к вопросу о переизобретении колес: ведь вот именно такие истории соблазняют людей изобретать управление пакетами заново, потому что на RPM/deb у них образуется слепое пятно и фобия. Тут люди говорят, что всякие расты и го — это будущее, Java тоже не последний игрок, но вот опакетить это по-человечески — сизифов труд, и еще при этом с дичайшим сопротивлением со стороны прекраснодушных идеалистов, которым всегда все не так, но как надо — ни объяснить, ни продемонстрировать они не могут.

Всё так.

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

Я так понимаю сейчас все в активном поиске. Грубо говоря джависты пошли по пути окукливания и отдельной репы - это javatools модуль. Поможет ли им это выжить - неясно. Ruby, go и python автоматизируют инструменты пакетирования и согласовывают rpm-спеки с апстримными. Nodejs бандлит библиотеки по-крупному. Про Haskell страшно говорить, там 400 мелких пакетов автогенерящихся скриптом.

Rust скорее всего тоже в сторону автоматизации двинется.

Я ни в коем случае не хочу сказать что rpm знает и может решить все проблемы пакетирования за раз в один прогон. Но, беда в том что апстримные разработчики, кроме питоновских, пока в принципе не готовы просто даже начать диалог с дистрибутивами. Они тупо отмахиваются и бегают со своими wget sudo bash, как будто так и положено.

И в такой атмосфере конечно ругани больше чем пользы.

…и немедленно выпил. :)

Они тупо отмахиваются и бегают со своими wget sudo bash, как будто так и положено.

пруфлинки в студию, пожалуйста

Вот такую штуку надо бы запилить в NixOS. Вроде бы там пока карга с инета тянет.

Запилено уже сто лет как, называется buildRustCrate.

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

Но так и не понял - а зачем вообще все это пакетировать? Какой юзкейс?

У жабы есть свои средства для подтягивания зависимостей при разработке. А деплоится жЫрный jar а то и вообще контейнер. Нет?

А теперь берём приложение типа eclipse. Его надо пакетировать или тоже jar и в контейнер?

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

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

Скачать инсталлер с офсайта и поставить в ~/somedirforeclipse ?

которые тупо не смогли договориться

тупо

ты серьёзно считаешь что эти люди тупее тебя?

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

Почему нет? Может. Только жабу-по-умолчанию надо через alternatives переключать. IDE нормально видят несколько разных установленных openjdk (проверял)