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

да потому что правильным решением было выкинуть 1.8 к чёрту. но нет, ынтерпрайз..

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

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

пекетного менеджера

и не только его, а в целом. и 1.8 выкинуть, наконец. в общем, они тут с питоном на пару в землю закопались.

айай. Можешь.

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

Вообще, с AppStore я смотрю, люди не понимают, что да как.

Смешной анонимус.

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

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

Да, я имел ввиду сборку «конечных» бинарников, то есть приложений. И либ с сишным интерфейсом. Всё же стабильный ABI у раста есть: repr(C), просто он не используется по умолчанию и поддерживает только совместимое с C подмножество раста 8).

Я всё ещё надеюсь что это можно исправить.

В так называемом «сообществе» это исправить нельзя. «Сообщество» — это такое место, где можно красноглазить до посинения и творить сферических коней в вакууме.

Red Hat/IBM могли бы это исправить, наняв команду из старых (по программистским меркам), прагматичных, немного циничных и презирающих любые идеологии хрычей, чтобы они сделали несовершенное, но работающее решение. Желательно таких, которым не сильно горит прописать в резюме кучу модных технологий для продолжения карьеры, и которым не западло работать над технологиями, которые не sexy.

Red Hat/IBM могли бы это исправить, наняв команду из старых (по программистским меркам), прагматичных, немного циничных и презирающих любые идеологии хрычей, чтобы они сделали несовершенное, но работающее решение. Желательно таких, которым не сильно горит прописать в резюме кучу модных технологий для продолжения карьеры, и которым не западло работать над технологиями, которые не sexy.

Эм, ну так это же я Ж)

А много там таких, как ты, задействовано в пакетной инфраструктуре? Кто у них менеджер или тимлид и имеет право сказать: «на стол упали вот такие варианты решения проблемы, от А до К, решение типа З — наилучшее с точки зрения простоты реализации и возможных подводных камней, идем работать»? После чего все идут реализовать вариант З, без ропота, саботажа, и «вот мне тут показалось, так будет лучше, поэтому я сделаю не так, как было решено».

Если такая команда есть, то она либо не имеет достаточно авторитета, либо ее работа не имеет достаточного приоритета, либо у вас любят играть в демократию там, где это не всегда уместно, потому что результата пока что нет, а ко времени Ф34 «либо ишак, либо падишах» — многое может еще перетасоваться.

Эм, ну так это же я Ж)

Насколько помню, мы одного года рождения, лично я еще недостаточно хрыч, ггггг )

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

В Fedora это невозможно чисто технически. Не важно кто ты по статусу, хоть тимлид хоть директор департамента. Я вот сейчас участник Fedora Council, но я никому и ничего не могу указать как делать, саботаж отменить тоже не могу. Единственное что у меня есть - это метод убеждающих flamewars, после которого и меня и остальных участников нужно неделю отпаивать бельгийским пивом. Что в текущей ситуации достаточно сложно.

Поэтому то что мы предложили сейчас сообществу - это отселить модули в песочницу, чтобы они были как бы при Fedora, но полностью опциональными. Чтобы старички не мешали их разработке, а новички не портили своими недоделками то, что работает.

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

Пока что даже это предложение насчет песочницы шло очень тяжело, три месяца ругани чтобы более менее придти к соглашению, но в итоге песочницу мы создали. Команда тоже обновилась и поменяла приоритеты: планы упростили и уменьшили запросы. Будем посмотреть.

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

отселить модули в песочницу, чтобы они были как бы при Fedora, но полностью опциональными.

Как это поможет в проблеме повторяемости сборки «технологий» которые имеют 10к+ «пакетов» (половина из которых это leftpad)?

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