Rust вот прекрасно себя чувствует

Сколько разных компиляторов у раста?

Сколько разных компиляторов у раста?

потому что на них легаси держится?

что значит "и", так кресты ж все про легаси!

кто-то говорит про прописывание этого в Стандарте?

ещё раз. У каждого дистра свои полиси для пакетирования. Всем не угодишь. Поэтому у нас для разработки свой пакетный менеджер, а для распространения в системе ПРИДЁТСЯ пакетить по правилам дистра (для этого мейнтейнеры и работают)

в комитете просто группу создали для думания над этим

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

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

Про во-первых. А кто-то говорил про несовместимое ABI? мне просто не нравится либа версии иной чем моя, потому что там снижение перфоманса\баг внутри\whatever else. Мб когда-нибудь апргрейднусь. Мб Про во-вторых, я понимаю конечно же. Я же сказал, я разраб этой либы, я так вижу.

Ну это все-таки очень общее рассуждение. Баг или снижение производительсти - это все-равно явный дефект, который нужно кому-то чинить. Если это происходит в рамках одной ветки со стабильным интерфейсом, то (при условии, что всё починено) не остается причины прилепать к определенной версии внутри. Если это разные ветки - ну так полно людей еще живет на openssl 1.0 и в ус не дует. Прилипнуть к определенной версии зависимости и статически с ними слинковаться - это задачка не про пакеты, к огромному сожалению. Отсутсвие каких-то проблем с безопасностью можно хоть как-то гарантировать только на голове поддерживаемой ветки библиотеки, потому-что туда хоть как-то смотрят её разработчики. К сожалению, некоторые авторы библиотек видят так, что у них есть "вечно стабильный мастер" где вперемешку меняется интерфейс, что-то исправляется, добавляются какие-то фичи. Это популярно, например, в golang. И проблема тут в том, что никто не знает что там было исправлено при очередном рефакторинге. Существуют задукоментированные случаи когда в glibc случайно ретроспективно находили косяки с демонстрацией эксплоита через exim, например, которые случайно(!) уже были исправлены три года назад при рефакторинге, но продолжающие жить в старых версиях. Вариантов решения этой проблемы три: либо ты забиваешь на безопасность своего проекта, либо ты инспектируешь все его зависимости (если у тебя есть очень много специалистов, которые могут решить эту задачу за конечное время), либо ты веришь наслово разработчикам каждой из зависимостей, что они ветку 2.4.x и 2.5.x поддерживают, а 2.3.x извините, они с завтрашнего дня выкидывают.

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

Да, flatpak это такой способ переложить ответственность

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

Я читал уже не раз. К Flatpak у меня те же вопросы возникают. Как мне удостоверится что там не лежит дырявая патченная версия openssl? Которая получит в итоге доступ к моим данным, потому-что приложением то я буду пользоваться.

а вообще где гарантии что запущенное приложение не потырит все что можно?

бандлы в системе это как пакеты, только бандлы?