> системные библиотеки = установленные в систему то есть в /usr/lib или еще
> куда нибудь
> установить туда можно что угодно

Хаха. Ты пробовал?

Не, ну ты вот сам подумай. Вот, допустим, ты пишешь софтину, которая не под Debian заточена, не под RedHat, не под Arch и не под Gentoo, ты пишешь софтину, задумывая её как кроссплатформенную промежь unix'ов. И теперь вопрос: как ты будешь при инсталляции своей софтины убеждаться, что в системе уже установлена libsomething-I-need-a-lot.so, причём достаточной версии?

configure? Эмм... ну это в принципе вариант, да. Если твой configure выдаст диагноз системе вида "здесь не установлена libsomething-I-need-a-lot.so.3.12" то это сработает: если человек снизошёл до запуска configure, то можно надеятся, что такое заявление подтолкнёт его у установки something-I-need-a-lot. Гарантировать этого нельзя, но если он не может, то это его проблемы.

A если не configure, то что? pkg-config? Это тоже вариант, но того же уровня.

rpm? apt-get? emerge? pacman? Но они не позволяют описать депенданс, которого нет в репах. В смысле, ты не сможешь проверить свой build/install-скрипт, не занеся предварительно в репы эту библиотеку. Но разработчик этой библиотеки считает, что возня с репами тысячи дистров -- это не та деятельность, которую он готов выполнять в качестве хобби. На самом деле, скорее всего, он не готов даже для одного репа поддерживать пакет: ему, в качестве хобби, интересно писать алгоритмы, реализовывать структуры данных, парсить синтаксисы, сериализовывать данные, но ему не интересно писать шелл-скрипты, под разные версии дистров, которые там что-то сделают. Ему не интересно связываться с бюрократией, которая требует десятка справок в трёх экземплярах, только для включения пакета в репы.

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

Покажи мне как можно установить в систему библиотеку, которая реализует для C строки вида struct {size_t len; size_t *bytes}. Которая реализует url_encode/url_decode. Которая позволяет легко получать выборки из различных распределений вероятностей. Которая позволяет легко форматировать данные в таблички, используя наилучшее возможное представление для терминала. Как это сделать? Так, чтобы часик повозиться единожды, и установить.

Нет такого способа. Linux-дистры не заточены под такое. Они распространяют лишь достаточно "серьёзные" библиотеки, которые достаточно часто используются. Если они попытаются двинутся хоть на полкарасика ниже, если они попытаются предоставлять больше библиотек, то их накроет dll-hell'ом, и мейнтейнеры linux'ов взвоют, и выкинут свои рабочие компьютеры от бессилия. dll-hell -- это фундаментальная проблема, есть разные способы справляться с ней, но ни один из них не является серебряной пулей. Подход linux-дистров не решает её, лишь снижает её влияние: по сравнению с вендой, он (за счёт трудов мейнтейнеров дистра) даёт возможность для ограниченного списка софта и депендансов иметь наилучшее решение проблемы. Всё что выходит за пределы ограниченного списка софта/депендансов, будет решать проблемы dll-hell так, как сможет. Причём дистры не предоставляют _ваабще_никаких_инструментов_ для этого. Программист вынужден костылить свои решения.

Тут могут помочь всякие решения, типа maven, gridle, cargo, npm, gem, pip, ..., но даже с ними возникают ОГРОМНЫЕ проблемы, если их пользовать через apt-get, emerge и тп. В том смысле, что все эти apt-get лишь добавляют больше проблем. Когда я игрался с ruby, я быстро забил на "emerge dev-ruby/something-i-need" и перешёл к использованию gem напрямую, устанавливая всё что нужно в $HOME. Потому что репы больше создают проблем в этом случае, чем решают. Они не могут найти решение для dll-hell в столь мелком разрешении: dll-hell -- это фундаментальная проблема со сложность O(exp(N)), под её решение не хватит никаких вычислительных ресурсов, и никаких человеческих ресурсов.

Самый простой способ для разработчика: оставить эти проблемы "кому-нибудь-ещё". Вот кому будет не лень с ними возиться, кому будет интересно или очень нужно, вот пускай он и возится.