나중에 제거할 수 있도록 Makefile을 저장합니까?

Goldilocks와 마찬가지로 지정된 src 폴더에 설치 파일을 저장합니다. 제 경우에는 /usr/local/src일 때도 있지만 일반적으로 /opt/src입니다. 저는 한 단계 더 나아갔습니다. 프로세스 전반에 걸쳐 타이프스크립트를 기록하기 위해 "스크립트"를 사용했고, 향후 사용을 기억하는 데 도움이 되도록 이러한 타이프스크립트 파일의 이름을 바꿨습니다. 소스와 같은 폴더에 저장합니다. 그런 다음 빌드와 설치가 만족스러우면 전체를 압축된 tarball로 패키징하고 /opt/src에 영구적으로 저장합니다.

소스에서 설치하고 1년 동안 보관할 만큼 유용한 것이 있으면 업스트림에서 버그 수정 및 보안 업데이트를 받기 위해 프로세스를 다시 반복해야 하기 때문에 이렇게 합니다. 그때가 되면 원본 파일을 풀어서 지난번에 무엇을 했는지, 결과물이 어땠는지 빨리 기억할 수 있는 곳으로 돌아가고 싶다.

한 단계 더 나아갈 수도 있습니다. 목표는 귀하 또는 귀하의 후임자가 미래에 소프트웨어를 안정적으로 업그레이드할 수 있도록 가능한 한 쉽게 만드는 것이어야 합니다. 따라서 미래의 자신에게 남길 수 있는 모든 단서는 좋은 것입니다. , 그리고 당신은 덜할수록 좌절감을 느끼고 나중에 시간을 낭비할 가능성이 더 커집니다.

미래의 자신을 위한 단서를 남기고 문제를 피하기 위한 다른 제안은 다음과 같습니다.

1. "스크립트"를 사용하여 설치 및 해당 출력을 기록한 다음 나중에 실수로 덮어쓰지 않도록 결과 TypeScript 파일의 이름을 바꿉니다. 빌드 폴더에 저장하세요.
2. 전후 정보를 수집하여 빌드 디렉터리에 저장합니다. 예를 들어, "ls -lR />before.ls-lr;...소프트웨어 설치...; ls -lR / >after.ls-lr". 대부분의 패키지 관리 도구에는 시스템에 대한 다양한 세부 정보를 확인하는 확인 옵션도 있습니다. 이에 대한 전후 비교를 수행하는 것이 도움이 됩니다. 모든 파일의 전체 md5sum을 수행하거나 트립와이어 또는 보조 도구와 같은 도구를 사용할 가치가 있습니다.
3. 설치 프로그램에 대해 회의적이어야 합니다. 설치 프로그램이 /var에 대한 권한을 모드 777로 변경하지 않거나 유사한 사악한 작업을 수행하지 않는다고 확신합니까? vimdiff와 같은 도구를 사용하여 재귀 파일 목록의 출력 전후를 비교하면 문제 해결 방법을 잊어버리기 전에 문제를 발견하는 데 도움이 될 수 있습니다.
4. 직접 메모를 남겨야 하는 경우 빌드 디렉터리에 메모를 넣으세요. 예를 들어 "README.bob"과 같은 파일은 "Bob"이 처음 발견한 작은 문제를 해결하는 데 도움이 됩니다. 다음 시간.

이러한 모든 노력은 일단 소프트웨어를 여러 시스템에 배포하기 시작하거나 시스템/데이터에 정말로 관심을 갖는 환경에서 성과를 거둘 것입니다.

한 단계 더 나아가 수백 개의 패키지 관리자 중 하나를 사용하여 자신의 시스템에 배포할 수 있는 패키지를 구축할 수 있습니다. 비슷한 도구를 사용하세요플루오로메틸메타크릴레이트, 그것은 간단합니다.

나는 makefile을 저장하지 않을 것입니다. 제거 대상이 그렇지 않을 수도 있지만(또는 아마도해서는 안 된다) 성공하려면 다른 것이 필요하지만 이것이 보장되는 것은 아닙니다.

이는 원본 패키지의 사본을 보관하는 것을 의미합니다. 하지만 공공 아카이브의 이전 버전이 있고 그것이 사라질까 봐 걱정하지 않는다면 그것은 별 의미가 없습니다. 어쨌든 나중에 다시 다운로드할 수 있습니다. 유일한 문제는 autotool 항목을 먼저 실행해야 하고 ./configure다른 옵션을 사용하면 uninstall뭔가를 놓칠 수 있다는 것입니다 . 그러나 나는 그것이 큰 문제라고 생각하지 않습니다. 때때로 나는 어떤 것의 특정 구성을 문서화합니다.

거기에 별도의 소스 패키지를 보관해 두었지만 /usr/local/src필요할 때 찾을 수 있다면 문제가 되지 않습니다.