Лично для себя нахожу неудобным стандартный принцип расположения установленных программ и компонентов. Когда приложения, библиотеки и прочее складываются в кучу в папках bin, lib, share и так далее. В принципе мне было бы по барабану, если бы я пользовался только менеджером пакетов. Но по факту бывают нужны самые свежие версии софта, например ставил gcc последней версии для отработки C++17. Соответственно приходится собирать все из исходников старыми добрыми configure, make , make install. И вот в этом случае приходится следить за всякими PATH, pkg-config, ldconfig.
Ладно если мне нужно просто поставить более свежую версию поверх старой: я тогда смотрю which ProgramName, если например выпало /usr/bin/ProgramName, то и при сборке ставлю --prefix=/usr и так далее по принципу. Только вот с библиотеками дело обстоит хуже: она может поставиться не в /usr/lib при заданном префиксе, а в какую-нибудь /usr/lib64 или /usr/lib/x86_64_linux-gnu или что-то в этом роде. В итоге нужная библиотека не записывается поверх, а их становится две версии в системе. Приходится править файлы в папке ld.so.conf.d и вызывать sudo ldconfig. Потом проверяю ldconfig -p, только он мне выдает, например, что есть чуть ли не пять ссылок libLibraryName.so на LibraryPath/libLibraryName.so. И как понять, какая в итоге библиотека используется? Вполне может оказаться так, что бинарник того же GCC будет запускаться последней версии, а библиотека libstdc++.so другой версии, если я ничего не путаю. А если на основе собранной из исходников свежей версии чего-либо нужно собрать из исходников свежую версию чего-то еще, то нужно маяться еще с pkg-config, чтобы configure был в курсе, что для сборки существует компонент свежей версии.
Я бы с удовольвствием ставил приложения по объектно-ориентированному принципу - Когда есть папка ComponentName (а она сама в каком-нибудь /opt например), а уже ее подпапки - это usr, lib, share , src, include и т.д. То есть чтобы в каталоге компонента были исключительно его данные и никакие другие. В таком случае и удалить установленный компонент легко, не парясь, есть ли make uninstall, не использовать построители пакетов, как напимер checkinstall и т.д. И иметь несколько версий компонента было бы нагляднее - были бо просто папки ComponentName-Version с данными.
Я просто хочу услышать мнение опытных - можно ли как-то грамотно устанавливать приложения по такому объектно-ориентированному принципу, грамотно прописывать библиотеки и делать pkg-config, как еще заставить компилятор дружить с кучей папок ComponentName/include в этом случае. Может ведь понадобиться действительно иметь несколько версий одного софта одновременно и выбирать для работы какой-то один в конкретное время и делать это по мановению файла-скрипта например.
Или это тухлая затея? И стоит мне прогнуться под правила Linux, а не Linux-u прогнуться под меня?
Я мог бы обойтись без такого принципа установки приложений, но как тогда при классических местах установки компонентов тотально контролировать на данный момент работающие версии или например удалить конкретную версию или компонент, не задев случайно другие файлы?
Если от моего поста веет «что-то мне не нравится linux» - это не так, просто хочу подстроить под себя. Система вроде как призвана как раз позволять настройку под себя.
P.S. Понимаю, что размещение базовых системных компонентов трогать не стоит, да и нафиг.
