Ubuntuリポジトリにソフトウェアの最新バージョンがないのはなぜですか?


145

公式のUbuntuリポジトリのパッケージが、Debian Sid、PPA、著者などの最新(上流)バージョンより古いのはなぜですか?


2
これは、Ubuntuだけでなく、あらゆるディストリビューションで実際に発生します
dr01

9
@ DR01常に最新情報を入手ローリング分布を有しているディストリビューションがあります-ので、すべてのディストリビューションは、この質問やUbuntuの開発サイクルに準拠していない
トーマス・ウォード

回答:


120

Ubuntuのリリースは、最終製品として実際に公開されるまでにいくつかの段階を経ます。

  • Ubuntuがリリースを開始する前に、特定の時点でパッケージをフリーズします。

  • リリースが出る前に、パッケージがフリーズした後、それらのパッケージに存在する可能性のあるすべてのバグと問題を修正するための作業がほとんど行われます。パッケージまたは機能のフリーズ後、新しいパッケージバージョンはリポジトリにインポートされなくなりました。

  • リリースが発生すると、これらのパッケージへの追加の変更は、バグ修正とセキュリティの問題に対してのみ発生します。パッケージの新しいバージョンがリリースされた場合でも、公式リポジトリ内のパッケージのアップグレードはこれ以上ありません。

パッケージの新しいバージョンは、次のフリーズが発生して同じプロセスが繰り返されるまで、Ubuntuの次のリリースのために一貫して(Debianから)インポートされます。

例として、12.04のリリーススケジュールを見ることができます。

4月に12.04がリリースされたにもかかわらず、1月12日にDebian Import Freezeと呼ばれるものが発生したことがわかります。

これは、実際のリリースの前に行われる多くのフリーズ段階の最初の段階であり、その時点でDebianテストまたは不安定版からのパッケージのインポートが停止し、それらの問題をカスタマイズおよび修正する作業が開始されます。

多くのパッケージでは、その時点以降にアップグレードは行われず、その時点でパッケージに含まれていたバージョンは、リリースの存続期間を通じて存在し維持されるバージョンです。

そのため、開発者のPPAまたはUbuntu + 1リポジトリに同じパッケージの上位バージョンがありますが、それらはUbuntuの次のリリースにのみ含まれます。

これは、安定性、セキュリティ、および機能のために行われます。常に新しいリポジトリがメインリポジトリにインポートされると、問題が解決され、さらに多くの問題が解決されます。パッケージバージョンのフリーズは、それを整理し、Ubuntuをエンドユーザーにとってより安全で安定したものにするのに役立ちます。

Ubuntuの新しいバージョンは6か月ごとにリリースされるため、6か月ごとに新しいパッケージが準備、テスト、カスタマイズされ、新しいバージョンでリリースされます。パッケージの将来のバージョンは、PPAを介して、またはWebサイトからダウンロードするだけでシステムにインストールできますが、公式リポジトリのパッケージのバージョンは同じままです。

Ubuntuの安定版リリースの完全な概要と説明については、10.04から12.04のリリースまでにUbuntuで何が起こったのかをより深く理解し、興味深い概要については、ReleaseSchedule-LTS to LTSおよびStable Release Updatesページ参照してください


2
このポリシーには、特にWebブラウザ(Firefox、Chromium)には例外があるようです。95%以上のパッケージが以下の指示に従う場合もありますが、ほとんどのユーザーにとってWebブラウザーが最もよく使用されるアプリケーションです。
dotpush

最新のソフトウェアが必要な場合は、Launchpad PPAリポジトリを使用してください。
iBug

@iBugまたはArch LinuxNixOSなどの異なるディストリビューションを使用するか、UbuntuシステムにHomebrewをインストールします。
ボリス

16

2つの理由。1つ目は非常に明白です。新しいアップストリームが出てきたときに、パッケージの更新に時間を費やす必要があります。2つ目は、現在の開発バージョンではなく安定したリリースを実行している場合、破損を防ぐために意図的にパッケージを意図的に更新しないことです。http://wiki.ubuntu.com/StableReleaseUpdatesを参照してください


3
「新しいアップストリームが出てきたら、パッケージの更新に時間を費やす必要があります」これは明らかに間違いであり、すべてを自動化できます。本当の理由は、あなたが言及した2番目の理由です。
18年

15

パッケージはリリースのために凍結され、いくつかの理由でその後更新されません。新しいリリースがリリース後に導入された場合、新しいバージョン...

  • 新しいバグをもたらす可能性があり、それによってリリース時に存在していた機能が後退する可能性があります
  • パッケージ化、テスト、およびアップロードするための人材が必要
  • 独自のセキュリティ更新プログラムのセットが必要
  • UIの翻訳を更新する必要があります
  • 更新されたドキュメント(および翻訳)が必要です。
  • 技術サポートをより困難にします
  • 古いバージョンの機能に慣れているユーザーを困らせる可能性があります
  • リポジトリ内で変更された他のアプリを破壊する可能性のある新しい依存関係が必要になる場合があります
  • これに依存する他のパッケージが破損する可能性があります
  • 古いバージョン用に作成されたユーザースクリプト、テンプレート、ツールなどが破損する可能性があります

とはいえ、リポジトリ内のソフトウェアバージョンの完全な更新をUbuntu 行う場合があることに注意しください。例えば、Firefox。

また、ユーザーが上記のような問題を引き起こさないアップデートパッケージを選択できるubuntu-backportsリポジトリがあります。デフォルトでは有効になっていないため、ユーザーはオプトインする必要があります。これは、ソフトウェアが下から変更されるという驚きを排除するために行われます。また、人員があまり多くないため、パッケージが実際に更新を取得する頻度はわかりません。

さらに、SRUチームは最近、ポリシーを少し更新しました。これにより、バグ修正のみのパッケージ更新を取得するのが少し簡単になります。


11

通常、Ubuntuのリリースバージョンの更新はセキュリティとバグ修正のためのものであり、そのようなバグの例は次のとおりです。

  • 現実的な状況下で、セキュリティの脆弱性を直接引き起こす可能性のあるバグ。これらはセキュリティチームによって行われ、SecurityTeam / UpdateProceduresで文書化されます。

  • Ubuntuの以前のリリースからの深刻なリグレッションを表すバグ。これには、アンインストール可能である、起動時にクラッシュするなど、まったく使用できないパッケージが含まれます。

  • 現実的な状況下で、ユーザーデータの損失を直接引き起こす可能性のあるバグ。上記のカテゴリに当てはまらないバグ。(1)明らかに安全なパッチがあり、(2)重要なインフラストラクチャパッケージ(X.orgなど)ではなくアプリケーションに影響するまたはカーネル)。

  • 長期サポートリリースでは、定期的に新しいハードウェアを有効にしたいと考えています。このような変更は、既存のハードウェアのアップグレードに影響を与えないようにするために適切です。たとえば、新しく導入されたドライバのモダリアは、以前に出荷されたドライバと重複してはなりません。-Canonicalパートナーアーカイブ内の商用ソフトウェアの新しいバージョン。

    -FTBFS(ソースからのビルドに失敗)も考慮することができます。メインでは、リリースプロセスにより、現在のソースからビルドされていないバイナリが存在しないことが保証されます。通常、これらのバグは、別のバグ修正と組み合わせてのみSRU化する必要があります。

    -新しい機能を提供するが、重大なバグを修正しないパッケージの新しいアップストリームバージョンの場合は、代わりにバックポートを要求する必要があります。

優れたウィキページStableReleaseUpdatesから取得


11

私はubuntuフォーラムやubuntu planetでの過去の経験に基づいてあなたの質問に答えようとします。

aptリポジトリがどのように更新され、誰によって更新されるのか疑問に思っているだけだと思います。

APTリポジトリは、Ubuntuのパッケージングチームから更新されます。パッケージングチームは、最初のパッケージングテストなどを行う開発者からすべてのアップストリームパッケージを取得します。その後、テストチームは最終テストを行い、合図を出します。ただし、パッケージングチームとテストチームは、依存関係とその安定したシステムへの影響について非常に慎重です。

遅れがある場合、それは開発者が関連するサーバーに最新のリリースをプッシュしていないためですか?

アップストリームの変更を見ると、パッケージをプッシュしたい何千人もの開発者がいます。しかし、すべてがメインストリームに成功しているわけではありません。これは、さまざまな理由によるものです。Geditアプリケーションを想定します。2.2バージョンが適していて、Dbus 2.1やGtk 2.4などで正常に動作します。Gedit2.4バージョン(非常に新しい)が動作するにはGtk 2.5とDbus2.3が必要です。現在、テストおよびパッケージングチーム(リリースチームも)はこれを受け入れません。古いdbusとgtkを持つ既存のシステムを新しいものに変更すると、他のすべてが壊れるからです。依存関係の地獄のポイントを得たことを願っています。

開発者がリポジトリを使用できる形式にリリースを取得するために、さらに多くの作業がありますか?

アップストリームチャネルではありません。しかし、リリースチャンネルにはい:)。

PS:上記で説明したものと比較して、標準になったプロセスに少し変更が加えられる可能性があります。しかし、多かれ少なかれ同じです。


6

コメントとして投稿されたリンクfossfreedomで受け入れられている答えは非常に良いです。

一般に、新しいリリース開発プロセスの最初の部分の後にリリースされたパッケージバージョンは、そのリリースのメインリポジトリに表示されないため、信頼性の高いUbuntuバージョンを徹底的にテストできます。

一部のパッケージは、将来のUbuntuリリースに正常に組み込まれ、開発者が以前のリリースでも機能すると信じている場合に、バックポートリポジトリにリリースされることがあります。バックポートは、ソフトウェアセンターで有効化および無効化できます([編集]-> [ソフトウェアソース]-> [更新]タブ-> [サポートされていない更新])


1
他の場所で述べたように、バックポートは一般的ではなく、多くはありません。
トーマス・ウォード

-3

答えはいっぱいではありません。

いくつかのパッケージがあり、Software Centerからバックポートバージョンにインストールできます。ウィンドウの右側、[インストール/変更]ボタンの左側に、バージョンを変更できる選択ボックスがあります。

例:デフォルトconkyは現在1.8.x1.9.0 (precise-backports)バックポートとしてあります。もちろん、最初にバックポートを有効にする必要があります。

ソース:http : //bugs.launchpad.net/ubuntu/+source/conky/+bug/1003727

編集:以下で説明するように、すべてのパッケージにバックポートがあるわけではありませんが、幸運な場合には、早期アクセスが可能な場合があります。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.