Это имеет тенденцию становиться немного беспорядочным. Вы получаете такие папки, как bin /, etc /, include, lib / и source / в вашей домашней папке.
По выбору, да. Если это кажется неопрятным, вы можете использовать вместо него
./configure --prefix=$HOME/mytools
. Затем вам нужно будет добавить это в свой $ PATH , или, если
$ HOME / bin
уже является его частью, вы можете переместить все, что есть сейчас, в$ HOME / mytools / bin
иrm ~/bin ln -s ~/mytools/bin ~/bin
Если ваши инструменты помещают что-то в
~ / mytools / lib
, вы также захотите установить где-нибудь соответствующий параметрLD_LIBRARY_PATH
.Если вы используете любой файл инициализации, который обычно используете для установки переменных env, это нужно сделать только один раз, и это займет около минуты.
Вы должны управлять зависимостями.
Если под «управлением» вы подразумеваете разрешение для целей установки, это основная цель
./ configure
. Если он не сделает это правильно, вряд ли сторонний инструмент сделает это намного лучше. Это может , но может и хуже .Если вы имеете в виду что-то еще, в концепции «зависимости» на самом деле нет ничего другого. Если вы имеете в виду, что вам нужно что-то, что решает эту проблему, загружает зависимость и устанавливает ее для вас, то для этого и нужны обычные менеджеры пакетов - но помните , вы решили, что вам не нужны предварительно созданные двоичные файлы . Вы строите из источника.
Очень жаль, что менеджеры пакетов Linux в основном недружелюбны или бесполезны для непривилегированных пользователей, но это отдельная проблема (и отдельный вопрос, на который есть разные ответы в зависимости от дистрибутива).
Есть ли инструмент для отслеживания ваших пакетов локально?
Да, сами пакеты с исходным кодом. При сборке распакуйте в
~ / mytools / src
. Вы можете оставить там каталог сборки или просто архив. Если вы хотите что-то удалить, просто войдите в соответствующий каталог (при необходимости распакуйте его снова) ивыполните деинсталляцию
.Каталог
src
никогда не используется системой ни для чего. Он содержит только то, что вы в него поместили, и, пока вы не удаляете свои загрузки, у вас есть хороший аккуратный список локально установленного программного обеспечения, созданного с исходным кодом, с источниками, фактически использованными для создания всего этого.
Si está seguro de que ejecutar el script con sudo
no le hará ningún daño (Por ejemplo, no creará nuevos archivos que ahora necesitarán root
privilegios, pero no lo harían de otra manera ), debe ejecutarlo con sudo
.
Si sabe que hay algunos efectos secundarios o no está seguro, hágalo de forma segura y use sudo
justo donde debe hacerlo.
En el encabezado del script pon esto:
#!/bin/bash
#Detects if script are not running as root...
if [ "$UID" != "0" ]; then
#$0 is the script itself (or the command used to call it)...
#$* parameters...
if whereis sudo &>/dev/null; then
echo "Please type the sudo password for the user $USER"
sudo $0 $*
exit
else
echo "Sudo not found. You will need to run this script as root."
exit
fi
fi