do-release-upgrade: Tidak Ada Rilis Baru Ditemukan

Mengapa do-release-upgrade menyatakan tidak ada rilis baru yang ditemukan

do-release-upgrade yang berakhir pada No new release found. hampir tidak pernah menunjukkan bahwa tool rusak. Jalur upgrade yang diminta sedang ditutup pada saat itu, dan tool melaporkannya dengan cara paling singkat. Ada lima hal yang dapat menutup jalur tersebut: pengaturan Prompt dalam /etc/update-manager/release-upgrades, syarat point release pada upgrade LTS (dukungan jangka panjang), repository pihak ketiga, package yang ditahan atau dikonfigurasi sebagian, serta rilis yang telah melewati masa dukungannya.

Periksa semuanya dalam urutan tersebut. Masing-masing memiliki perintah untuk membuktikan apakah kondisi itu berlaku pada server Anda. Dengan demikian, Anda tidak perlu menebak kondisi mana dari kelima hal tersebut yang sedang terjadi.

Hal yang sebenarnya dilaporkan oleh flag check-only

sudo do-release-upgrade -c
echo $?

-c hanya melakukan pemeriksaan. Perintah ini membaca metadata rilis Canonical melalui HTTPS (hypertext transfer protocol secure) dan mencetak hasilnya. Perintah ini tidak mengunduh alat pemutakhiran dan tidak menulis ulang file source. Ada dua keluaran penting:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Exit code menyampaikan hasil yang sama untuk skrip. Nilainya 0 jika rilis tersedia dan 1 jika tidak ada rilis, yang merupakan kebalikan dari konvensi shell biasa. Karena itu, baca hasilnya dengan cermat sebelum menggunakannya sebagai dasar pemeriksaan.

Jika banner login masih menampilkan hasil lama, berarti hasil tersebut tersimpan di cache. Baris itu berasal dari /etc/update-motd.d/91-release-upgrade, yang mencetak hasil tersimpan tanpa meminta informasi ke jaringan. Segarkan hasilnya dengan sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, atau cukup percayai -c. Banner hanya mengulangi hasil pemeriksaan terakhir yang dijalankan.

Pemeriksaan ini juga harus dapat menjangkau changelogs.ubuntu.com. Pada server di balik firewall outbound yang ketat atau proxy yang tidak dapat diakses oleh tool, perintah tersebut tidak dapat mengirim permintaan. Akibatnya, perintah tidak dapat menemukan rilis apa pun.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Baris HTTP/2 200 berarti server dapat melihat metadata. Baris curl: (28) Connection timed out berarti aturan egress adalah penyebab sebenarnya. Mengedit file APT (advanced package tool) sebanyak apa pun tidak akan mengubah hasilnya.

Jika perintah tersebut tidak tersedia sama sekali, perintah itu terdapat dalam ubuntu-release-upgrader-core. Image cloud minimal terkadang tidak menyertakan package tersebut.

sudo apt install ubuntu-release-upgrader-core

Baca /etc/update-manager/release-upgrades sebelum mengubah apa pun

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

File tersebut memiliki dokumentasinya sendiri dalam komentar. Tiga nilai yang valid adalah:

• never: jangan pernah memeriksa atau mengizinkan upgrade ke rilis baru.
• normal: tawarkan rilis yang didukung dan langsung mengikuti rilis yang sedang digunakan.
• lts: tawarkan rilis LTS pertama yang mengikuti rilis yang sedang digunakan.

Prompt=never adalah yang paling mudah didiagnosis karena tool tersebut menyebutkan nama file dan pengaturannya dalam output:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Penyedia hosting dan tool manajemen konfigurasi menetapkan never secara sengaja untuk mencegah fleet berpindah-pindah antar-rilis. Jika Anda menemukannya di sana, berarti seseorang menetapkannya. Ubah nilainya menjadi lts untuk server yang ingin Anda pertahankan pada jalur dukungan jangka panjang, lalu kembalikan ke nilai sebelumnya jika automasi Anda mengharapkan nilai lama tersebut.

Satu detail dalam komentar tersebut sering menimbulkan masalah. Jika Prompt=lts ditetapkan dan rilis yang sedang digunakan bukan rilis LTS, upgrader memperlakukan pengaturan tersebut sebagai normal. Pada mesin 25.10, kedua nilai tersebut berperilaku sama. Pada mesin 24.04, keduanya tidak sama. Perbedaan itulah yang menjadi pokok bahasan bagian berikutnya.

Mengapa upgrade dari LTS ke LTS menunggu point release pertama

Prompt menentukan file metadata yang dibaca oleh upgrader. Alamatnya berada di /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts membaca meta-release-lts. Prompt=normal membaca meta-release. Kedua file tersebut menjelaskan setiap release dalam blok kecil berisi beberapa key, dan upgrader hanya menawarkan suatu release jika flag Supported:-nya bernilai 1. Baca file tersebut langsung dari server yang sama:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Diperiksa pada 13 August 2026, kedua file tersebut memberikan informasi yang berbeda tentang Ubuntu 26.04. File LTS menyatakan:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

File biasa menyatakan:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Nilai Supported: 0 dalam file LTS adalah gate-nya. Server 24.04 yang menggunakan Prompt=lts default membaca file tersebut, tidak menemukan release LTS yang lebih baru dan ditandai tersedia, lalu menampilkan No new release found. Tidak ada yang salah pada mesin Anda. Canonical belum membuka jalur upgrade tersebut.

Flag berubah menjadi 1 ketika point release pertama dirilis. Ubuntu 26.04.1 dijadwalkan dirilis pada 27 August 2026, tetapi jadwal rilis dapat berubah. Karena itu, periksa metadata, bukan kalender. Point release bukan versi baru Ubuntu, melainkan rilis yang sama dengan seluruh pembaruan sejak peluncuran yang digabungkan ke media instalasi baru. Jadi, bagi server yang sedang berjalan, yang penting adalah akses yang dibuka, bukan media itu sendiri. Penundaan ini disengaja. Pengguna yang melakukan upgrade lebih awal menemukan masalah penghambat, lalu masalah tersebut diperbaiki sebelum populasi server LTS yang jauh lebih besar mengikutinya. Jika tanggal tersebut telah berlalu saat Anda membaca ini, isi 26.04.1 saat dirilis dan artinya bagi server 24.04 melanjutkan pembahasannya dari sana.

Ada dua opsi yang benar-benar masuk akal. Tunggu point release. Ini adalah pilihan yang tepat untuk server yang tidak ingin terus Anda pantau. Atau, tetapkan Prompt=normal, yang mengarahkan alat yang sama ke meta-release, tempat 26.04 sudah ditandai sebagai versi yang didukung. Opsi kedua akan meng-upgrade sistem ke 26.04 yang sudah dirilis, bukan ke build pengembangan. Karena itu, opsi ini masih dapat dipertanggungjawabkan pada mesin yang dapat dipulihkan dari snapshot. Setelah selesai, kembalikan nilainya ke lts. Prosedur lengkapnya, langkah demi langkah, tersedia di panduan lengkap upgrade server dari 24.04 ke 26.04. Server yang masih menggunakan 22.04 harus melalui satu tahap tambahan karena Prompt=lts hanya menawarkan rilis LTS berikutnya. Jadi, jalur dari 22.04 ke 26.04 harus melalui 24.04 terlebih dahulu.

Repositori pihak ketiga dan PPA yang menghambat upgrade

Alat upgrade menulis ulang sumber APT agar mengarah ke rilis baru. Alat ini hanya dapat melakukannya untuk repositori yang menyediakan paket untuk rilis baru. Sumber lainnya akan dinonaktifkan dengan menambahkan komentar. Alasannya dicetak satu baris untuk setiap entri dan bersifat spesifik: was disabled (unknown mirror), was disabled (unknown dist), dan was disabled (no Release file).

PPA (personal package archive) yang dibuat untuk noble tidak memiliki direktori untuk resolute di server. Karena itu, alat upgrade tidak dapat mengambil file Release untuk seri baru dan menonaktifkan entri tersebut. Biasanya, ini hanya peringatan yang dapat Anda terima. Masalah ini menjadi penghambat ketika repositori pihak ketiga menyediakan paket yang juga disertakan dalam rilis baru. Dalam kondisi tersebut, perhitungan upgrade memiliki dua kandidat dan tidak dapat memenuhi keduanya.

Tentukan hal ini sebelum memulai. Jangan biarkan alat mengambil keputusan selama proses unattended yang berlangsung lama.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy pada nama paket menampilkan asal repositori untuk setiap versi yang terpasang. Dengan demikian, Anda dapat melihat secara tepat paket mana yang bergantung pada sumber yang akan dinonaktifkan. Menghapus sumber tidak menurunkan versi paket. Jadi, paket yang dipasang dari PPA tetap menggunakan versi dari PPA dan dapat lebih baru daripada versi yang tersedia dalam rilis baru. Jika hal ini berpengaruh, hapus paket tersebut juga, lalu pasang ulang dari archive setelah upgrade selesai. Repositori yang ingin Anda aktifkan kembali, seperti milik Tailscale, harus diperbarui codenamenya ke rilis baru sebelum paket dapat dipasang kembali. Hal inilah yang menyebabkan sebagian besar error instalasi Tailscale di Ubuntu.

Tersedia flag untuk memilih opsi sebaliknya. Halaman manual menjelaskan --allow-third-party sebagai "Mencoba upgrade dengan mirror dan repositori pihak ketiga tetap diaktifkan, bukan menonaktifkannya dengan menambahkan komentar." Gunakan opsi ini hanya setelah memastikan bahwa repositori tersebut sudah menyediakan paket untuk rilis target. Jika belum, Anda meminta APT menyelesaikan grafik dependensi terhadap seri yang belum pernah dibuat oleh repositori tersebut.

Pada Ubuntu 24.04 dan versi setelahnya, sebagian besar sumber berada di /etc/apt/sources.list.d/ubuntu.sources dalam format deb822. Repositori yang sama jika ditulis dalam format lama dan format baru merupakan error terpisah dengan pesan tersendiri. Hal ini dibahas dalam error entri sumber duplikat dalam format deb822.

Paket yang tertahan dan belum dikonfigurasi menghentikan perhitungan

Upgrade rilis harus memindahkan hampir semua paket pada sistem. Jika satu paket tidak dapat dipindahkan, perhitungan gagal, dan upgrader lebih baik berhenti lebih awal daripada meninggalkan sistem dalam keadaan setengah selesai. Dua perintah dapat menemukan penyebabnya.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold mencetak paket yang ditahan, satu paket per baris, dan tidak mencetak apa pun pada sistem yang bersih. Penahanan adalah instruksi manual agar paket tersebut tidak pernah diubah. Seseorang mungkin menahan versi kernel atau database, lalu melupakannya. Lepaskan penahanan paket yang tidak lagi diperlukan dengan sudo apt-mark unhold diikuti nama paket.

dpkg --audit mencantumkan paket yang sudah dibongkar, tetapi belum dikonfigurasi. Kondisi ini terjadi karena proses instalasi terhenti, paling sering akibat sesi yang terputus. Upgrader mencoba memperbaikinya dan mencetak dpkg interrupted, calling dpkg --configure -a, tetapi menjalankan perbaikan sendiri terlebih dahulu memungkinkan Anda membaca error, bukan membiarkannya berlalu saat proses berjalan. Jika tool tidak dapat memperbaiki suatu paket, tool akan menghasilkan pesan Package in inconsistent state. Paket tersebut harus ditangani sebelum Anda mencoba lagi.

Perbarui rilis yang sedang berjalan sepenuhnya sebelum melakukan upgrade.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Opsi phased updates lebih penting daripada yang terlihat. Ubuntu meluncurkan sebagian pembaruan ke persentase mesin tertentu secara bertahap. Karena itu, apt upgrade biasa dapat dengan benar meninggalkan beberapa paket, sehingga server menjadi kurang mutakhir daripada yang Anda kira. Opsi tersebut mengambil semuanya. Lakukan reboot setelahnya jika pembaruan menyertakan kernel, sehingga upgrade dilakukan dari kernel yang benar-benar sedang dijalankan. Server yang sudah menjaga dirinya tetap diperbarui melalui upgrade keamanan otomatis memiliki lebih sedikit pekerjaan pada tahap ini, meskipun mekanisme tersebut memang tidak pernah melintasi batas rilis.

Ketika rilis telah melewati akhir dukungan standar

Rilis interim Ubuntu didukung selama sembilan bulan. Ketika dukungan tersebut berakhir, flag Supported: berubah menjadi 0, dan jalur normal tidak menyediakan pemutakhiran dari rilis tersebut. Berdasarkan pemeriksaan pada 13 August 2026, meta-release menyatakan hal berikut tentang 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

Arsip juga berpindah pada saat yang sama. Paket untuk rilis yang telah mencapai akhir masa pakai dihapus dari archive.ubuntu.com dan disimpan di old-releases.ubuntu.com. Akibatnya, apt update mulai mengembalikan 404 Not Found, sistem tidak dapat lagi dimutakhirkan, dan karena pemutakhir mengharuskan sistem dalam kondisi terkini, proses tidak dapat dilanjutkan. Perbaiki sumber paket terlebih dahulu.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Arahkan archive.ubuntu.com dan security.ubuntu.com ke old-releases.ubuntu.com, dan jangan mengubah codename Anda. Hanya nama host yang berubah.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Jalankan perintah yang sama terhadap /etc/apt/sources.list jika server Anda masih menyimpan sumber paket dalam satu file tersebut. Opsi -i.bak menulis cadangan di sebelah file asli, sehingga Anda dapat mengembalikannya jika perubahan diterapkan pada file yang salah. apt update yang berhasil setelah itu berarti arsip dapat diakses kembali, dan do-release-upgrade kini akan berfungsi.

Bersikaplah realistis mengenai hasil yang dapat dicapai. Ubuntu mendukung satu langkah rilis setiap kali, sehingga server yang tertinggal dua atau tiga rilis yang telah berakhir masa pakainya harus melalui setiap langkah secara berurutan. Setiap langkah dapat gagal karena repositori pihak ketiga atau paket yang ditahan. Pada VPS, sering kali lebih cepat membuat server baru dengan LTS terkini, memindahkan layanan ke sana, lalu mempertahankan server lama sampai Anda yakin semuanya berjalan baik. Cara ini juga menyediakan rollback, yang tidak pernah tersedia pada pemutakhiran di tempat. Jika Anda memilih jalur rilis yang akan digunakan setelahnya, perbedaan antara LTS dan rilis interim pada server layak dibaca sebelum Anda memutuskan.

Fungsi sebenarnya dari flag development release

-d atau --devel-release membuat upgrader membaca meta-release-development, bukan file yang dipilih oleh Prompt. Halaman manual menjelaskannya sebagai "Jika menggunakan rilis terbaru yang didukung, lakukan upgrade ke development release."

Diperiksa pada 13 August 2026, entri terbaru dalam file tersebut bukan 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Jadi, -d tidak memberikan 26.04 yang sudah dirilis kepada server 24.04. Flag tersebut mengarah ke 26.10, yaitu rilis yang masih dalam proses pengembangan. Saran lama untuk "cukup menambahkan -d" ditulis untuk periode sebelum LTS dirilis. Jika diulangi sekarang, saran itu akan mengarahkan server ke rilis yang tidak Anda maksudkan. Jika Prompt=lts masih digunakan, flag tersebut berhenti dan menampilkan pesannya sendiri:

There is no development version of an LTS available.

Dokumentasi server Ubuntu menjelaskan flag tersebut secara langsung: "menggunakan development release (atau flag -d) tidak direkomendasikan untuk lingkungan produksi". Development release berubah setiap hari dan tidak memiliki jaminan dukungan keamanan. Karena itu, paket yang berfungsi pada pagi hari dapat membuat service gagal pada sore hari. Gunakan rilis ini pada virtual machine sementara yang dibuat untuk menguji konfigurasi Anda sendiri. Jangan menggunakannya pada server yang diperlukan oleh pengguna atau layanan apa pun. Jika Anda ingin menggunakan 26.04 yang sudah dirilis sebelum LTS gate dibuka, Prompt=normal adalah cara yang benar.

Jalankan upgrade di tempat yang tidak dapat terputus oleh sesi SSH

Upgrade rilis mengganti sebagian besar sistem, termasuk openssh-server dan systemd. Jika sesi SSH (secure shell) Anda terputus saat dpkg bekerja, proses akan dihentikan ketika sebagian paket sudah diekstrak dan belum dikonfigurasi. Kondisi ini biasanya menyebabkan percobaan berikutnya gagal. Jika hal tersebut sudah terjadi, memulihkan upgrade yang terhenti di tengah proses merupakan tugas terpisah dan harus diselesaikan sebelum percobaan kedua. Selalu mulai upgrade di dalam terminal multiplexer.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Jika koneksi terputus, masuk kembali lalu jalankan tmux attach -t upgrade. Upgrade tetap berjalan karena proses tersebut merupakan turunan dari server tmux, bukan dari sesi SSH Anda. screen -S upgrade dan screen -r upgrade menjalankan fungsi yang sama jika Anda lebih memilih screen.

Upgrade menyediakan mekanisme pengamanan sendiri bagi pengguna yang tidak memakai multiplexer. Saat mendeteksi bahwa proses berjalan melalui SSH, upgrade menawarkan untuk menjalankan sshd kedua pada port 1022. Dengan demikian, sesi utama yang terputus masih menyisakan jalur untuk masuk kembali. Upgrade menentukan kondisi ini dengan menelusuri proses induknya sendiri untuk mencari proses bernama sshd. Di dalam tmux atau screen, penelusuran tersebut menemukan server multiplexer sebagai gantinya. Karena itu, tawaran tersebut tidak muncul, dan file PID /var/run/release-upgrader-sshd.pid hanya ditulis jika daemon tambahan benar-benar dijalankan. Tidak ada masalah jika prompt tersebut tidak muncul. Anda sudah memiliki perlindungan yang lebih baik.

Jika Anda menerima tawaran tersebut, port itu tidak dibuka secara otomatis. Tool tersebut menjelaskannya dengan tegas karena membuka port merupakan keputusan keamanan yang tidak berhak diambilnya atas nama Anda. Buka port tersebut selama upgrade berlangsung, lalu tutup kembali setelahnya.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

Sebagian besar penyedia VPS menjalankan firewall kedua pada control panel mereka, di luar sistem operasi. Port 1022 juga harus dibuka di sana. Jika tidak, listener fallback berjalan tetapi tidak dapat dijangkau. Ini merupakan kondisi yang paling buruk.

Empat hal berikut harus disiapkan sebelum Anda mengetikkan perintah:

• Buat snapshot atau backup lengkap. Upgrade rilis di tempat tidak dapat dibatalkan, dan ini satu-satunya kesempatan Anda untuk memulihkan sistem.
• Pastikan Anda dapat membuka console penyedia sebelum membutuhkannya. Jika server tidak kembali setelah reboot, SSH adalah hal yang tidak akan tersedia. Kernel yang gagal boot merupakan masalah terpisah dengan langkah pemulihannya sendiri, yang dibahas dalam VPS yang tidak dapat boot setelah pembaruan kernel.
• Periksa ruang kosong dengan df -h / /boot. Upgrade mengunduh seluruh set paket, dan partisi /boot yang menyimpan beberapa kernel lama sering menjadi tempat proses terhenti.
• Baca catatan rilis untuk service yang Anda jalankan. Lompatan versi mayor pada PostgreSQL atau PHP hadir bersama rilis tersebut, terlepas dari apakah Anda sudah merencanakannya.

FAQ

Mengapa do-release-upgrade menyatakan tidak ada rilis baru yang ditemukan pada Ubuntu 24.04?

Nilai default Prompt=lts di /etc/update-manager/release-upgrades membuat alat tersebut membaca https://changelogs.ubuntu.com/meta-release-lts, dan Ubuntu 26.04 menetapkan Supported: 0 di file itu sampai point release pertamanya. Upgrader tidak menemukan rilis LTS yang lebih baru dan ditandai tersedia, sehingga proses berhenti. Periksa file tersebut sendiri dengan curl -s https://changelogs.ubuntu.com/meta-release-lts dan baca blok terakhir. Saat diperiksa pada 13 August 2026, flag tersebut masih 0, sedangkan Ubuntu 26.04.1 dijadwalkan pada 27 August 2026.

Apakah aman menetapkan Prompt=normal daripada menunggu point release?

Proses ini meng-upgrade sistem ke 26.04 yang sudah dirilis, bukan ke build pengembangan, karena Prompt=normal membaca meta-release, dan 26.04 sudah memiliki Supported: 1 di sana. Risikonya terletak pada waktu pelaksanaan. Anda melakukan upgrade sebelum masalah yang ditemukan oleh pengguna awal diperbaiki. Lakukan pada server yang dapat dipulihkan dari snapshot dan yang dapat Anda akses melalui konsol provider jika reboot gagal. Setelah itu, kembalikan nilainya ke lts.

Apakah flag -d meng-upgrade sistem saya ke 26.04?

Tidak. -d membaca meta-release-development, dan entri terbarunya pada 13 August 2026 adalah Ubuntu 26.10, yaitu rilis yang masih dalam pengembangan. Pada mesin LTS dengan Prompt=lts, flag tersebut menampilkan There is no development version of an LTS available. lalu berhenti. Dokumentasi server resmi Ubuntu menyatakan bahwa rilis pengembangan tidak direkomendasikan untuk production, jadi gunakan Prompt=normal jika ingin menggunakan 26.04 yang sudah dirilis lebih awal.

apt update mengembalikan error 404 pada rilis lama. Bagaimana cara meng-upgrade-nya?

Rilis tersebut sudah mencapai end of life, sehingga paketnya dipindahkan dari archive.ubuntu.com ke old-releases.ubuntu.com. Ubah hanya nama host di /etc/apt/sources.list.d/ubuntu.sources, atau di /etc/apt/sources.list pada layout yang lebih lama, dan biarkan codename tetap sama. Kemudian jalankan sudo apt update dan sudo apt full-upgrade. Setelah sistem kembali mutakhir, do-release-upgrade dapat memindahkannya ke rilis berikutnya satu per satu.

Apakah saya perlu menghapus PPA sebelum menjalankan do-release-upgrade?

Tidak perlu, karena upgrader akan memberi komentar pada source yang tidak menyediakan paket untuk rilis baru dan menampilkan baris seperti was disabled (no Release file) untuk setiap source tersebut. Namun, melakukannya sendiri terlebih dahulu lebih baik karena Anda dapat menentukan urutannya dan melihat hasilnya. Jalankan apt policy pada paket yang Anda perlukan untuk mengetahui paket yang berasal dari setiap PPA, lalu instal ulang paket tersebut dari archive jika versi PPA lebih baru daripada versi yang tersedia pada rilis baru.