Belajar Linux - Package Management di Berbagai Distro

#Pendahuluan

Setelah di episode 10 sebelumnya kita membahas hak akses administrator dan sudo management — mulai dari bahaya login sebagai root, perbedaan su - vs sudo, konfigurasi /etc/sudoers dengan visudo, sampai memberikan NOPASSWD untuk otomatisasi — kalian kini punya kunci administratif yang aman. Di episode kali ini, kunci itu akan kita gunakan untuk hal paling fundamental yang dilakukan seorang admin Linux: mengelola perangkat lunak.

Salah satu alasan pertama kali orang "jauh" dari Linux adalah kebingungan saat ingin menginstal aplikasi: di Windows tinggal klik .exe, di macOS tinggal seret .dmg, tapi di Linux malah harus mengetik perintah seperti apt install nginx. Sebenarnya justru inilah kekuatan terbesar Linux. Episode ini akan menjelaskan mengapa package manager ada, bagaimana tiga keluarga distro besar — Debian/Ubuntu, RHEL, dan Arch — menjalankannya, serta format-format universal yang mengisi celah di antaranya. Mari kita mulai.

#Pembahasan Utama

#Mengapa Linux Memakai Package Manager?

Anggap saja .exe/.dmg itu seperti menemukan kotak sparepart di pinggir jalan: kalian tidak pernah tahu persis isinya, dari mana asalnya, apakah versinya cocok dengan sistem kalian, dan tidak ada catatan siapa yang sudah mengambil apa. Setiap .exe dari internet membawa versi library sendiri-sendiri, menaruh file di lokasi yang semaunya, dan tidak berkoordinasi dengan aplikasi lain. Akibatnya: dua aplikasi bisa membawa versi library yang bentrok, dan tidak ada cara terpusat untuk tahu "aplikasi apa saja yang terpasang di mesin ini?".

Package manager menghapus semua teka-teki itu dengan empat konsep kunci:

1. Repository terpusat — software diambil dari server resmi distro (mirror) yang sudah diverifikasi, bukan dari sembarang tautan internet.
2. Metadata lengkap — setiap paket membawa nama, versi, deskripsi, dependensi, dan checksum. Sistem tahu persis apa yang akan terpasang sebelum memasangnya.
3. Dependensi otomatis — apt install nginx otomatis menarik semua library yang dibutuhkan Nginx. Tidak ada lagi drama "install library ini dulu secara manual".
4. Manajemen terpusat — satu basis data mencatat seluruh paket terpasang. Menghapus aplikasi benar-benar bersih, dan update bisa dilakukan di seluruh sistem sekaligus.

Inilah mengapa pernyataan "Linux tidak punya .exe" adalah kesalahpahaman: Linux memang sengaja tidak punya, karena .exe adalah solusi yang kacau. Model package manager lebih mirip iOS App Store atau Play Store — satu sumber terpercaya, update terpusat, dan mesin tahu status setiap aplikasi.

#Keluarga Debian/Ubuntu: APT

APT (Advanced Package Tool) bekerja di atas paket .deb dan membaca daftar repository dari /etc/apt/sources.list dan /etc/apt/sources.list.d/. Ada dua perintah yang wajib dibedakan sejak awal: apt update memperbarui daftar paket yang tersedia di repository (metadata), sedangkan apt upgrade memperbarui paket yang terpasang itu sendiri. apt update tidak menginstal apa pun; ia hanya menyegarkan katalog.

# Segarkan katalog paket dari repository
sudo apt update
 
# Tingkatkan seluruh paket yang terpasang
sudo apt upgrade
 
# Instal paket baru (beserta dependensinya)
sudo apt install nginx
 
# Hapus paket (tanpa file konfigurasi)
sudo apt remove nginx
 
# Hapus dependensi yang sudah tidak terpakai
sudo apt autoremove

Untuk mencari dan memeriksa paket, APT menyediakan apt search dan apt show:

apt search nginx
apt show nginx

apt show adalah kebiasaan yang sangat disarankan sebelum install: ia menampilkan versi, dependensi, ukuran, dan terutama deskripsi — sehingga kalian tahu persis apa yang akan terpasang. Di produksi, melakukan apt search dulu juga menghindari kesalahan menginstal paket dengan nama mirip (misalnya nginx-core vs nginx).

#Keluarga RHEL: DNF

DNF (Dandified YUM) adalah penerus yum di keluarga RHEL — Rocky Linux, AlmaLinux, Fedora. Filosofinya sama dengan APT, tapi dengan terminologi yang berbeda. Tidak ada dnf update untuk katalog; alih-alih, dnf check-update memeriksa ketersediaan pembaruan dan dnf update atau dnf upgrade menerapkannya.

# Periksa pembaruan yang tersedia (tanpa menerapkan)
sudo dnf check-update
 
# Terapkan semua pembaruan
sudo dnf update
 
# Instal paket
sudo dnf install nginx
 
# Hapus paket
sudo dnf remove nginx
 
# Cari paket
sudo dnf search nginx

Salah satu keunggulan DNF yang menonjol adalah transaction summary: sebelum mengeksekusi, DNF menampilkan paket yang akan diinstal, ditingkatkan, dan dihapus, lalu meminta konfirmasi. Ini memberi kalian kesempatan membaca apa yang akan berubah — kebiasaan audit yang sangat berharga di produksi.

#Keluarga Arch: Pacman

Pacman adalah package manager Arch Linux. Arsitekturnya rolling release: tidak ada versi "distro" yang naik setahun sekali — pembaruan datang terus menerus. Karena itu satu ritual wajib yang tidak bisa ditawar adalah pacman -Syu setiap kali hendak menginstal sesuatu. Mari bedah opsinya:

# Refresh + upgrade semua paket terlebih dahulu
sudo pacman -Syu
 
# Instal paket
sudo pacman -S nginx
 
# Hapus paket beserta dependensi yang tak terpakai
sudo pacman -Rs nginx

#Perbandingan Langsung Tiga Keluarga Distro

Supaya pola di atas makin jelas, berikut perbandingan perintah yang setara di ketiga keluarga. Perhatikan bagaimana tiga package manager yang berbeda ternyata melakukan hal yang persis sama:

sudo apt update            # segarkan katalog
sudo apt upgrade           # upgrade semua
sudo apt install nginx     # install paket
sudo apt remove nginx      # hapus paket
apt search nginx           # cari paket

sudo dnf check-update      # periksa pembaruan
sudo dnf update            # upgrade semua
sudo dnf install nginx     # install paket
sudo dnf remove nginx      # hapus paket
dnf search nginx           # cari paket

sudo pacman -Sy            # segarkan katalog
sudo pacman -Syu           # upgrade semua
sudo pacman -S nginx       # install paket
sudo pacman -Rs nginx      # hapus paket + dependensi
pacman -Ss nginx           # cari paket

Pola yang sama dalam bahasa yang berbeda — inilah yang membuat seorang admin bisa berpindah antar distro dengan cepat: begitu memahami konsep (refresh catalog → install → upgrade → remove → search), perintah hanyalah kosakata baru. Yang membedakan bukan lagi "cara menginstal", melainkan kebijakan: seberapa sering upgrade, bagaimana repositori pihak ketiga ditangani, dan seberapa ketat validasi sebelum perubahan diterapkan.

#Format Paket Universal: Snap, Flatpak, dan AppImage

Ketiga keluarga di atas sama-sama punya kelemahan: sebuah paket yang di-build untuk Ubuntu bisa gagal di Arch. Solusi dari masalah "satu biner untuk semua distro" ini lahir dalam tiga format universal. Mereka mengatasi masalah dependency hell dengan cara berbeda: menyatukan aplikasi beserta seluruh dependensinya ke dalam satu sandbox yang terisolasi dari sistem.

# Snap
sudo snap install code --classic
 
# Flatpak (setelah menambahkan repo Flathub)
flatpak install flathub org.audacityteam.Audacity
 
# AppImage — unduh satu file, beri izin eksekusi, jalankan
chmod +x ./SomeApp.AppImage
./SomeApp.AppImage

#Kesalahan Umum dalam Package Management

Jebakan paling umum terjadi justru pada dua perintah yang terlihat mirip: apt update dan apt upgrade. Kebanyakan masalah "repository gagal di-refresh" atau "paket tidak ditemukan" berasal dari lupa menjalankan apt update setelah menambah repository baru. Ingat alurnya: tambah repository → apt update → baru apt install. Menginstal langsung setelah menambah PPA tanpa apt update akan menghasilkan error "Unable to locate package".

Di sisi lain, sudo apt upgrade di mesin produksi bukan keputusan sepele. Kalian bisa tiba-tiba mendapatkan versi kernel baru, library yang berubah perilaku, atau konfigurasi service yang ditimpa. Di produksi, kebijakan umumnya adalah jangan upgrade sembarangan: pin versi paket tertentu, uji di staging, dan jadwalkan upgrade di window pemeliharaan. apt upgrade bukan apt-get dist-upgrade (yang bisa mengubah dependensi secara agresif), tapi tetap saja — mengubah ratusan paket di mesin live tanpa tes adalah cara tercepat membuat downtime.

Kesalahan ketiga yang sangat umum adalah PPA yang rusak. PPA (Personal Package Archive) di Ubuntu adalah repository pihak ketiga yang kadang ditinggalkan penulisnya. Gejalanya khas: apt update error dengan pesan "404 Not Found" untuk satu repo tertentu. Solusinya bukan menghapus semua PPA, melainkan menonaktifkan repo bermasalah:

# Cari tahu repo mana yang gagal — pesan 404 menyebut URL-nya
sudo apt update
 
# Daftar PPA yang terpasang
find /etc/apt/sources.list.d/ -name "*.list" -exec cat {} \;
 
# Hapus PPA yang ditinggalkan
sudo add-apt-repository --remove ppa:some-owner/abandoned-repo

#Penutup

Pada episode 11 ini kita telah memetakan seluruh lanskap package management: memahami mengapa Linux memilih repository terpusat alih-alih installer .exe/.dmg, mempraktikkan siklus hidup lengkap apt, dnf, dan pacman, membandingkan ketiganya dalam satu tabel perintah yang setara, serta mengenal format universal snap, flatpak, dan AppImage beserta trade-off masing-masing. Pelajaran terpentingnya: package manager bukan sekadar "cara install aplikasi" — ia adalah sistem manajemen kedaulatan software yang membuat mesin bisa diaudit, di-update, dan di-reproduce.

Setelah aplikasi-aplikasi terpasang dengan benar, pertanyaan berikutnya adalah: bagaimana Linux tahu harus mencari program di mana? Jawabannya ada di environment variables, terutama PATH. Di episode 12 selanjutnya kita akan membahas shell dan environment variables — dari VAR=x vs export VAR, variabel penting seperti HOME, LANG, dan PS1, hingga kustomisasi .bashrc dengan alias dan fungsi, plus script bash pertama kalian. Sampai jumpa!