Отслеживание программ

Когда я устанавливаю простую программу, она часто использует make && make installи даже не имеет цели удаления .

Если я хочу обновить программу, это стандартный протокол, предполагающий, что она просто переписывает поверх старой программы?

Как я отслеживаю эти программы; большинство людей просто «запускают и забывают», и если цель удаления не указана, нужно ли мне удалять все вручную?

Установите каждую программу в отдельном дереве каталогов и используйте Stow или XStow, чтобы все программы отображались в общей иерархии. Stow создает символические ссылки из директории программы на общее дерево.

Более подробно, например, выберите каталог верхнего уровня /usr/local/stow. Установите каждую программу под /usr/local/stow/PROGRAM_NAME. Например, организуйте установку исполняемых файлов /usr/local/stow/PROGRAM_NAME/bin, страниц руководства /usr/local/stow/man/man1и т. Д. Если программа использует autoconf, то запустите ./configure --prefix /usr/local/stow/PROGRAM_NAME. После запуска make installзапустите stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

И теперь у вас будут такие символические ссылки:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Вы можете легко отслеживать, какие программы вы установили, перечислив содержимое stowкаталога, и вы всегда знаете, к какой программе принадлежит файл, потому что это символическая ссылка на местоположение в каталоге этой программы. Удалите программу, запустив и stow -D PROGRAM_NAMEудалив каталог программы. Вы можете сделать программу временно недоступной, запустив ее stow -D PROGRAM_NAME(запустите, stow PROGRAM_NAMEчтобы сделать ее снова доступной).

Если вы хотите иметь возможность быстро переключаться между разными версиями одной и той же программы, используйте /usr/local/stow/PROGRAM_NAME-VERSIONв качестве каталога программы. Чтобы обновить версию 3 до версии 4, установите версию 4 и запустите stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Старые версии Stow не выходят далеко за рамки основ, которые я описал в этом ответе. Более новые версии, а также XStow (который не поддерживался в последнее время) имеют более продвинутые функции, такие как возможность игнорировать определенные файлы, лучше справляться с существующими символическими ссылками за пределами каталога хранения (например, man -> share/man), автоматически обрабатывать некоторые конфликты (когда два программы предоставляют один и тот же файл) и т. д.

Если у вас нет или вы не хотите использовать root-доступ, вы можете выбрать каталог в вашем домашнем каталоге, например ~/software/stow. В этом случае добавьте ~/software/binв свой PATH. Если manне удается автоматически найти справочные страницы, добавьте их ~/software/manна свою страницу MANPATH. Добавьте ~/software/infoк вашему INFOPATH, ~/software/lib/pythonк вашему PYTHONPATHи так далее в зависимости от обстоятельств.

Вы можете использовать checkinstall для создания пакета (RPM, Deb или Slackware-совместимые пакеты). Таким образом, вы можете использовать менеджер пакетов distros для добавления / удаления приложения (но не для обновления).

Вы используете checkinstallвместо make installкоманды (используя параметр -D для Deb; -R - это RPM, а -S - Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall соберет и установит пакет по умолчанию, или вы можете сделать так, чтобы пакет собирался только без установки.

checkinstall доступно в большинстве репозиториев дистрибутивов.

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

Я бы сказал, что удаление вручную - это единственный способ установки вручную, если у кого-то еще нет лучшего ответа на этот вопрос, о котором я, возможно, не знаю.

Еще одна альтернатива из подсказок Linux From Scratch :

Больше контроля и управления пакетами с использованием пользователей пакетов

3 Пакетные пользователи
3.1 Введение

Основная идея этой схемы легко объяснима. Каждый пакет принадлежит определенному «пользователю пакета». Когда вы устанавливаете пакет, вы создаете и устанавливаете пакет как этот пользователь пакета, в результате чего все установленные файлы принадлежат пользователю пакета. Как следствие, все обычные задачи управления пакетами могут быть легко достигнуты с помощью стандартных утилит командной строки. Простое ls -l <file>скажет вам, например, к какому пакету <file>принадлежит, а find -user ...команда позволяет вам выполнить операцию со всеми файлами, принадлежащими определенному пакету, например, удалить их, чтобы удалить пакет.

Но управление пакетами - это еще не все, для чего нужны пользователи пакетов. Поскольку пользователи пакета не имеют рут-прав, установка пакета ограничена в том, что он может делать. Например, пользователь пакета не имеет права перезаписывать файлы другого пользователя пакета. Столкновения между различными пакетами, которые хотят установить двоичный файл, библиотеку или заголовочный файл с одним и тем же именем, встречаются чаще, чем вы думаете. С пользователями пакета вы никогда не рискуете уничтожить установочные файлы пакета B из пакета A без уведомления. Каждая попытка сделать это во время установки пакета B приведет к ошибке «Отказано в доступе» или «Операция не разрешена», чтобы у вас была возможность предпринять соответствующие шаги. Еще одна вещь, которую пользователям пакетов не разрешается делать, это устанавливать корневые двоичные файлы setuid. Решение сделать двоичный корень setuid - это то, что разумный администратор не хочет оставлять на усмотрение создателя программного пакета.

Обычно учетные записи пользователей пакета не имеют действительного пароля, поэтому только пользователь root может su получить доступ к пакету, что гарантирует, что пользователи пакета не открывают дополнительный путь в систему и не подрывают безопасность. Но вы все равно можете установить пароли, чтобы позволить со-администратору, которого вы хотите, устанавливать и обслуживать определенные пакеты программного обеспечения, не имея доступа к реальной учетной записи root. Этот соадмин может, например, устанавливать, удалять, изменять дополнительные библиотеки, которые могут понадобиться его рабочей группе. Однако он не сможет удалить или изменить библиотеки, которые ему не принадлежат, такие как libc.

После этого первого грубого предложения я нашел усовершенствованный вариант:

crablfs - система управления пакетами на основе пользователя

Это crablfsпоследний образец управления пакетами, использующий уникальные uid и gids для управления пакетами, но в sourceforge он снова развивается в ulfs:

uLFS: ваш управляемый и многократно используемый Linux с нуля

Для причинных пользователей установленных пакетов, я думаю, что LFS-решение «пакетных пользователей» является легким, менее инвазивным и элегантным. Короче говоря, вы устанавливаете пакеты в /usr/localили /home/user/localи отслеживаете файлы, используя уникальные uid и gids для каждого пакета, но помещаете все файлы в традиционные места, общие каталоги /usr/local/bin, /usr/local/libкак это есть во всех основных дистрибутивах Linux ... окклюзия файлов и нежелательная перезапись или удаление файлов избегается изящной уловкой Linux, объясненной Матиасом С. Бенкманом в more_control_and_pkg_man.txt, которая требует только обычных манипуляций с разрешениями файлов и каталогов, например, разрешением на закрепление битов для каталогов, чтобы избежать нежелательной перезаписи файлов:

3.3 Группы

Каждый пользователь пакета принадлежит как минимум двум группам. Одной из этих групп является группа «install», к которой принадлежат все пользователи пакета (и только пользователи пакета). Все каталоги, в которые разрешено устанавливать пакеты, относятся к группе установки. Это включает в себя каталоги, такие как / bin и / usr / bin, но исключает каталоги, такие как / root или /. Каталоги, принадлежащие группе установки, всегда доступны для записи в группе. Этого будет достаточно для аспектов управления пакетами, но без дальнейшей подготовки это не даст дополнительной безопасности или контроля, поскольку каждый пакет может заменить файлы из другого пакета (изменение будет видно в выходных данных изls -l, хотя). По этой причине все установочные каталоги получают атрибут sticky. Это позволяет пользователям создавать новые файлы и удалять или изменять свои собственные файлы в каталоге, но файлы от других пользователей не могут быть изменены или удалены. В остальной части этой подсказки всякий раз, когда используется термин «каталог установки», он относится к каталогу, который принадлежит группе установки, доступен для записи в группе и является липким. IOW, чтобы превратить <dir>в каталог установки, вы бы сделали

chgrp установить && chmod g + w, o + t

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

1. Вы можете сделать пустой RPM в качестве напоминания.
2. Вы можете посмотреть, как правильно обернуть программу в RPM.
3. Вы можете оставить копию tarфайлов из установки, /usr/src/non-rpmsчтобы напомнить вам (это то, что я обычно делаю).