공식 리포지토리에서 업데이트 된 최종 사용자 소프트웨어를 찾기가 어려운 이유는 무엇입니까? [닫은]

아니요, 이것은 /ubuntu/151283/why-dont-the-ubuntu-repositories-have-the-latest-versions-of-software 의 중복이 아닙니다 .

내 질문은 최종 사용자 소프트웨어에만 해당됩니다. 나는 저급 패키지와 물건에 관한 안정성 주장을 완전히 이해하지만 며칠마다 업데이트 할 패키지가 많이 있지만 왜 공통 응용 프로그램에 관한 패키지가 없습니까?

이로 인해 많은 개발자가 공식 저장소를 사용하지 말라고 제안하는 부조리가 생겼습니다. Google Play / App Store에는 1 년 된 버전 만 포함되어 있기 때문에 소파에서 웹 어디에서나 APK / IPA를 다운로드해야하는 모바일 세상을 상상해보십시오.

그것이 우분투에서 일어나는 일입니다. 사용하기 쉬운 소프트웨어 설치 방법의 마법은 너무 오래 되었기 때문에 완전히 망가졌습니다.

예 : 방금 컴퓨터에 Ubuntu 16.04가 설치되었으며 Calibre 버전은 거의 5 개월이되었습니다. 2.55는 리포지토리에 있고 2.66은 이미 종료되었습니다.

원래 개발자가 PPA를 유지 관리하는 데 신경 쓰지 않는다면 우리는 옛날 학교에서 다운로드 사이트에 액세스하고 tarballs 또는 debs를 얻고 수동으로 물건을 설치해야합니다. 우분투는 시원했지만 지금은 Windows보다 오래되었습니다.

인적 요소가 유일한 반응입니까? Ubuntu 관리자는 Ubuntu 버전 사이의 모든 소프트웨어 릴리스를 유지하는 것보다 더 많은 일을해야합니다 . 소프트웨어 개발자가 Ubuntu 리포지토리에서 자신의 소프트웨어를 업데이트하는 것이 더 쉬운 이유는 무엇입니까?

소프트웨어 개발자가 Ubuntu 리포지토리에서 자신의 소프트웨어를 업데이트하는 것이 더 쉽고 쉬운 이유는 무엇입니까?

소프트웨어 개발자는 소프트웨어를 정기적으로 업데이트합니다. 그래서 새로운 Calibre 버전을 찾았습니다. 그러나 업데이트를 Ubuntu 리포지토리로 직접 푸시하지는 않습니다. 그 이유는 질문과 연결된 답변에 이미 나와 있습니다.

PPA를 항상 제공 할 수있는 것은 아닙니다. PPA에 추가적인 부담이 가중되기 때문입니다. 그런 다음 여러 배포판에 패키지를 제공해야합니다. 그리고 각 배포판에는 여러 가지 비 EOL 릴리스가 있습니다. Ubuntu 용 패키지를 제공하려면 16.04, 14.04 및 아마도 12.04 용 패키지를 만들어야합니다. 그런 다음 Fedora, Debian, Arch 사용자가 불평을 시작합니다! 쉽지 않습니다! 그렇기 때문에 일반적으로 타사 유지 관리자가 PPA를 제공합니다.

그러나 요즘 개발중인 최종 사용자에게 최신 소프트웨어를 제공하는 또 다른 대안이 있습니다. 응용 프로그램의 모든 구성 요소를 단일 파일로 패키징합니다. 대부분 컨테이너와 같은 격리 된 환경에서 실행되며 시스템에 설치된 현재 라이브러리와 호환되지 않아도됩니다. 예를 들어, 주로 3.18 구성 요소와 함께 패키지 된 Xenial에서 gtk-3.20 응용 프로그램을 실행할 수 있습니다.

그러나 그들도 문제가 있습니다! (각주 참조)

몇 가지 접근 방식은 다음과 같습니다.

• AppImages
• 그놈의 FlatPak
• 우분투에 의해 스냅

우분투 관리자는 우분투 버전 사이의 모든 소프트웨어 릴리스를 유지하는 것보다 더 많은 일을해야합니까?

우분투 관리자는 각 릴리스의 이정표를 맞추려고 노력합니다. 우분투를 안정적으로 유지하려면 모든 패키지가 예상대로 작동하는지 확인해야합니다. 예를 들어, 최근에 문제가되었다 여기에 질문 KDEConnect 1.0 우분투 16.04에 최신을 얻기에 관하여. 그러나 kdeconnect1.0에는 Qt 5.6이 필요하다는 것이 밝혀졌습니다 . Qt 5.6을 제공하려면 공식 저장소의 다른 패키지가 제대로 작동하는지 확인해야합니다. 즉, 모든 KDE 패키지를 다시 빌드하고 다시 테스트한다는 것은 정말 큰 작업입니다.

최신의 최신 소프트웨어가 필요한 경우 롤링 릴리스 배포판 또는 질문에서 앞서 언급 한 다른 단일 패키지 방식을 사용해 볼 수 있습니다 .

단일 파일 패키징의 일부 문제 :

1. 그들은 일반적으로 크기가 더 큽니다 (필요한 모든 것을 포장하기 때문에)

2. 이를 설치하면 시스템에 각 패키지가 사용하는 동일한 라이브러리의 여러 사본이 있으므로 시스템을 더 크게 만듭니다.

3. 이러한 패키징 형식을 사용하려면 패키지 관리자가 라이브러리 자체와의 통합을 테스트해야합니다. 이것은 그들에게 추가적인 부담입니다. 와 apt, yum접근 방식, 그것들은 오직 코어 응용 프로그램과 방해한다. 배포판에서 lib-gtk-xy-1.5를 사용할 수 있다고 가정 할 수 있습니다.

4. 다시 한 번, 같은 이유로 패키지 관리자는 패키지에 포함 된 라이브러리와 관련된 버그 보고서로 귀찮게됩니다. 전통적인 접근 방식에서 이것은 특정 lib 패키지의 관리자가 담당했습니다.