소스 코드는 공개되지 않거나 무료가 아니므로 설치 시 컴파일하는 것은 옵션이 아닙니다. 지금까지 만난 개발자들:
- tar.gz 파일이 제공되며 적절한 위치에 압축을 푸는 것은 사용자의 몫입니다.
- install.sh 스크립트와 함께 .tar.gz를 제공하여 기본 설치 프로그램을 실행하고 사용자에게 설치 옵션을 묻는 메시지를 표시할 수도 있습니다.
- RPM 및/또는 deb 파일을 제공하면 사용자는 설치/업그레이드/제거를 위해 친숙한 기본 패키지 관리 도구를 계속 사용할 수 있습니다.
빌드/패키징/설치 인프라를 최대한 적게 유지하면서 최대 수의 Linux 배포판을 지원하고 사용자의 삶을 최대한 쉽게 만들고 싶습니다.
내 소프트웨어를 패키징하는 방법에 대한 조언을 찾고 있습니다.
답변1
나는 그것을 보는 두 가지 방법이 있다고 생각합니다.
하나는 가장 널리 사용되는 Linux용으로 각 Linux에 대한 기본 패키지를 제공하고 인기순으로 패키지를 제공합니다. 몇 년 전만 해도 이는 먼저 Red Hat 유형 Linux용 RPM을 제공한 다음 시간이 허락하는 대로 덜 인기 있는 각 RPM 기반 Linux용 소스 RPM을 재구축하는 것을 의미했습니다. 이것이 Mandriva RPM이 일반적으로 Red Hat 또는 SuSE RPM보다 약간 오래된 이유입니다. 그러나 지난 몇 년 동안 Ubuntu가 인기를 끌면서 .deb로 시작한 다음 나중에 RPM을 추가할 수도 있습니다.
또 다른 방법은 노력하고 목표를 세우는 것입니다.모두즉시 사용 가능한 Linux를 제공하는 것이 바로 바이너리 타르볼을 제공하는 사람들이 하려는 일입니다. 시스템 관리자이자 최종 사용자로서 저는 이 옵션을 별로 좋아하지 않습니다. 이러한 타르볼은 압축을 푼 시스템 전체에 파일을 분산시켜 제거, 패키지 확인, 스마트 업그레이드 및 기타 세부 사항을 나중에 수행할 수 없도록 만듭니다.
가장 인기 있는 Linux용 기본 패키지, 이상한 Linux용 바이너리 타르볼, 어떤 이유로 패키지 관리자를 좋아하지 않는 구식 시스템 관리자 등 하이브리드 접근 방식을 시도해 볼 수 있습니다.
답변2
내가 선호하는 것은 항상 패키지(rpm|deb 등)입니다. 소프트웨어의 특성에 따라 특정 배포판(rhel/centos 등)에 대한 패키지를 대상으로 하는 것이 가치가 있을 수 있지만 모든 사람에게 충분한 패키지가 없을 수도 있습니다.
스크립트를 설치하면 스크립트에 따라 다릅니다. 패키지되지 않은 소프트웨어에 대해 나에게 가장 중요한 점은 내가 선택한 위치에 쉽게 설치할 수 있다는 것입니다.
답변3
게임은 게임을 접두사에 깔끔하게 설치하고 아이콘과 같은 작업을 처리하는 설치 프로그램(이전 Loki Installer, 현재 MojoSetup)을 사용하는 경향이 있습니다.