Вы сохранили бы Make-файл для более позднего удаления?
] Как и Goldilocks, я храню установочные файлы в папке, обозначенной src -- в моем случае иногда это /usr/local/src, но часто это /opt/src. Я делаю шаг вперед -- я использую 'скрипт' для записи скрипта на протяжении всего процесса, и я переименовываю эти типизированные файлы, чтобы помочь мне вспомнить, для чего они были нужны позже. Я храню их в той же папке, что и исходники. Затем, когда я удовлетворяюсь, что сборка и установка были хорошими, я заворачиваю всё это в сжатый тарбол и храню его практически вечно под /opt/src.[
] []Я делаю это, потому что всегда, если что-то достаточно полезное, чтобы установить из исходников и продержаться около года, мне придётся повторить процесс ещё раз, чтобы получить исправления ошибок и обновления безопасности из апстрима. Когда придет это время, я хочу вернуться в одно место, распаковать исходный файл и быстро вспомнить, что я делал в прошлый раз, вместе с тем, что получилось в результате.[
] []Вы даже можете пойти дальше - помните, цель должна состоять в том, чтобы сделать как можно проще для вас или для человека, который придет за вами, надежно обновить программное обеспечение в будущем, так что каждая подсказка, которую вы можете оставить в будущем - это хорошо, и чем меньше вы это делаете, тем больше вероятность того, что в конечном итоге вы будете разочарованы и сожжёте время позже.[
] []Вот другие предложения по подсказкам, чтобы оставить себя и способы избежать проблем в будущем: [
] [- ]
[
- ]Используйте "сценарий" для записи установок и их вывода; затем переименуйте получившиеся типизированные файлы, чтобы случайно не перезаписать их позже. Храните их в папке сборки.[ ] [
- ]Собирайте информацию до и после и храните ее в папке сборки. Например, можно сделать "ls -lR / >before.ls-lr; []...install software...[]; ls -lR / >after.ls-lr". Большинство инструментов управления пакетами также имеют опцию верификации, которая позволяет выкладывать всевозможные подробности о вашей системе - это полезно. Иногда также стоит сделать полную md5-сумму всех файлов или использовать такие утилиты, как трипвайр или помощник.[ ] [
- ]Подозрительно относитесь к программе установки -- вы уверены, что она не изменяет права доступа в режиме 777 в /var или не делает ничего подобного гнусного? Сравнение вывода списка рекурсивных файлов до и после с таким инструментом, как vimdiff, может помочь вам обнаружить проблемы до того, как вы забудете, как их исправить.[ ] [
- ]Если вам нужно оставить свои заметки, поместите их в каталог сборки -- например, файл типа "README.bob" поможет "Bobу" с любыми маленькими догадками, которые вы обнаружите в первый раз, и которые вы можете забыть в следующий раз. [ ] [
]Все эти усилия окупятся, как только вы начнете распространять программу на куче систем, или в окружении, где вы действительно заботитесь о системе/данных.[
] []Вы можете сделать шаг вперёд и использовать любой из сотен менеджеров пакетов для сборки пакета, который вы можете распространять в своих системах. С таким инструментом, как []FPM[], это просто.[
].] Я бы не стал хранить только макфайл. Хотя цель деинсталляции может и не нуждаться (или perhap, []не должна []) в чем-либо еще, это не является гарантией.[
] []Так что это означает сохранение копии оригинального пакета. Однако, нет особого смысла, если есть общедоступный архив старых версий, и вы не беспокоитесь о том, что он исчезнет. Вы можете просто скачать его позже в любом случае. Единственная проблема в том, что для работы с автоуправлением сначала нужно запустить []./configure[], и если вы используете различные опции []uninstall[], возможно, что-то пропустите - но это не так уж и важно, я думаю. Иногда я сохраняю заметки о конкретной конфигурации чего-то.[
]Я храню независимые пакеты исходных текстов в []/usr/local/src[], но это не имеет значения, пока вы можете найти их, когда вам это нужно.[