Відстеження програм

Коли я встановлюю просту програму, вона часто використовує 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 (який останнім часом не підтримується) мають більш вдосконалені функції, такі як здатність ігнорувати певні файли, краще справлятися з існуючими посиланнями поза каталогом Stow (наприклад man -> share/man), обробляти деякі конфлікти автоматично (коли два програми надають один і той же файл) тощо.

Якщо у вас немає або не хочете користуватися кореневим доступом, ви можете вибрати каталог під домашнім каталогом, наприклад ~/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 ...команда дозволяє виконати операцію над усіма файлами, що належать певному пакету, наприклад, видаліть їх для видалення пакета.

Але управління пакетами - це не все, для чого користувачі пакунків хороші. Оскільки користувачі пакету не мають root-прав, установка пакету обмежена тим, що він може робити. Одне, що користувачеві пакету заборонено робити, наприклад, це перезаписати файли іншого користувача пакета. Сутички між різними пакетами, які хочуть встановити бінарний, бібліотечний або заголовний файл з тим самим іменем, зустрічаються частіше, ніж можна подумати. З користувачами пакету ви ніколи не ризикуєте встановити пакет B, знищивши файли з пакета A мовчки, не помічаючи. Кожна спроба зробити це під час встановлення пакету B призведе до помилки "Дозвіл відмовлено" або "Операція не дозволена", щоб у вас була можливість вжити відповідних кроків. Інша річ, яку користувачі пакету забороняють робити, це встановити встановлені кореневі бінарні файли. Рішення зробити коріння бінарного настроюваного корі - це також те, що розсудливий адміністратор не хоче залишати лише творцю програмного пакету.

Зазвичай облікові записи користувачів пакету не мають дійсного пароля, так що su користувач пакету може виконувати лише root , що гарантує, що користувачі пакету не відкриють додатковий шлях до системи та підривають безпеку. Але ви можете все-таки встановити паролі, щоб дозволити співавтору, якому ви хочете мати змогу встановлювати та підтримувати певні програмні пакети, робити це, не маючи доступу до власного кореневого облікового запису. Наприклад, цей адміністратор може встановити, видалити, змінити додаткові бібліотеки, які можуть знадобитися його робочій групі. Однак він не зможе видалити або змінити бібліотеки, які не належать йому / їй, наприклад, libc.

Після цієї першої грубої пропозиції я знайшов розвинений варіант:

crablfs - Система управління пакетами на основі користувачів

Це crablfsнайновіший зразок управління пакунками, що використовує унікальні посібники та посібники для управління пакунками, але в sourceforge він знову еволюціонує в ulfs:

uLFS: Ваш керований та багаторазовий Linux з нуля

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

3.3 Групи

Кожен користувач пакету належить щонайменше до 2 груп. Однією з цих груп є група «встановити», до якої належать усі користувачі пакунків (і лише користувачі пакунків). Усі каталоги, у яких пакетам дозволено встановлювати речі, належать до групи встановлення. Сюди входять каталоги, такі як / bin та / usr / bin, але виключаються каталоги типу / root або /. Каталоги, що належать групі встановлення, завжди доступні для запису групи. Цього буде достатньо для аспектів управління пакетом, але без подальшої підготовки це не дасть додаткової безпеки або контролю, оскільки кожен пакет міг би замінити файли з іншого пакету (зміна буде видно у висновку зls -l, хоча). З цієї причини всі встановлені каталоги отримують атрибут sticky. Це дозволяє користувачам створювати нові файли та видаляти або змінювати власні файли в каталозі, але файли інших користувачів не можна змінювати чи видаляти. У решті цього підказу, щоразу, коли використовується термін "каталог встановлення", він посилається на каталог, який належить до групи встановлення, є груповим записом та липким. IOW, щоб перетворитись <dir>на каталог встановлення, який ви зробили б

chgrp install && chmod g + w, o + t

Для мене це виглядає як просте і розумне рішення! Я використовував цю схему в моїй збірці LFS, і це робоче рішення ...

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