Apa pro / kontra dari deb vs rpm?

Untuk alasan apa pun, saya selalu menggunakan distribusi berbasis RPM (Fedora, Centos dan saat ini openSUSE). Saya sudah sering mendengarnya menyatakan bahwa deb lebih baik daripada rpm, tetapi ketika ditanya mengapa, tidak pernah bisa mendapatkan jawaban yang koheren (biasanya mendapatkan beberapa nyanyian semangat dan jumlah ludah yang berlebihan sebagai gantinya).

Saya mengerti mungkin ada beberapa alasan historis, tetapi untuk distribusi modern menggunakan dua metode pengemasan yang berbeda, adakah yang bisa memberikan manfaat teknis (atau lainnya) dari satu vs. lainnya?

Perbedaan utama untuk pengelola paket (saya pikir itu akan menjadi 'pengembang' dalam istilah Debian) adalah cara paket meta-data dan skrip yang menyertainya bergabung.

Dalam dunia RPM, semua paket Anda (RPM Anda mempertahankan) berada dalam sesuatu seperti ~/rpmbuild. Di bawahnya, ada SPECdirektori untuk file-spec Anda, SOURCESdirektori untuk tarbal sumber, RPMSdan SRPMSdirektori untuk memasukkan RPM dan SRPM yang baru dibuat, dan beberapa hal lain yang tidak relevan sekarang.

Segala sesuatu yang berkaitan dengan bagaimana RPM akan dibuat ada dalam file-spesifikasi: tambalan apa yang akan diterapkan, skrip pra dan pasca yang mungkin, meta-data, changelog, semuanya. Semua tarbal sumber dan semua tambalan dari semua paket Anda berada di SUMBER.

Sekarang, secara pribadi, saya menyukai kenyataan bahwa semuanya masuk ke file spesifikasi, dan file spesifikasi adalah entitas yang terpisah dari tarball sumber, tetapi saya tidak terlalu antusias memiliki semua sumber di SUMBER. IMHO, SUMBER akan berantakan cukup cepat dan Anda cenderung kehilangan jejak apa yang ada di sana. Namun pendapat berbeda.

Untuk RPM, penting untuk menggunakan tarball yang sama persis dengan yang dikeluarkan oleh proyek upstream, hingga stempel waktu. Secara umum, tidak ada pengecualian untuk aturan ini. Paket-paket Debian juga membutuhkan tarball yang sama dengan upstream, meskipun kebijakan Debian mengharuskan beberapa tarball untuk dikemas ulang (terima kasih, Umang).

Paket Debian mengambil pendekatan yang berbeda. (Maafkan kesalahan apa pun di sini: Saya jauh kurang berpengalaman dengan deb dibandingkan dengan RPM.) File pengembangan paket Debian dimuat dalam direktori per paket.

Apa yang saya (pikirkan) sukai tentang pendekatan ini adalah kenyataan bahwa semuanya terkandung dalam satu direktori.

Di dunia Debian, sedikit lebih diterima untuk membawa tambalan dalam paket yang belum (belum) hulu. Di dunia RPM (setidaknya di antara turunan Red Hat) ini disukai. Lihat "Proyek Fedora: Tetap dekat dengan proyek-proyek hulu" .

Juga, Debian memiliki sejumlah besar skrip yang dapat mengotomatisasi sebagian besar pembuatan paket. Sebagai contoh, membuat paket - sederhana - program Python setuptool'ed, semudah membuat beberapa file meta-data dan menjalankannya debuild. Yang mengatakan, file spesifikasi untuk paket tersebut dalam format RPM akan sangat singkat dan di dunia RPM, juga, ada banyak hal yang otomatis hari ini.

Banyak orang membandingkan menginstal perangkat lunak dengan apt-getuntuk rpm -i, dan oleh karena itu mengatakan DEB lebih baik. Namun ini tidak ada hubungannya dengan format file DEB. Perbandingan sesungguhnya adalah dpkgvs rpmdan aptitude/ apt-*vs zypper/ yum.

Dari sudut pandang pengguna, tidak ada banyak perbedaan dalam alat ini. Format RPM dan DEB keduanya hanya mengarsipkan file, dengan beberapa metadata terlampir. Keduanya sama-sama misterius, memiliki jalur instalasi hardcoded (yuck!) Dan hanya berbeda dalam detail halus. Keduanya dpkg -idan rpm -itidak memiliki cara untuk mencari tahu cara menginstal dependensi, kecuali jika mereka ditentukan pada baris perintah.

Di atas alat-alat ini, ada manajemen repositori dalam bentuk apt-...atau zypper/ yum. Alat-alat ini mengunduh repositori, melacak semua metadata, dan mengotomatiskan pengunduhan dependensi. Instalasi akhir dari setiap paket tunggal diserahkan ke alat tingkat rendah.

Untuk waktu yang lama, apt-gettelah unggul dalam memproses sejumlah besar metadata sangat cepat sementara yumakan butuh waktu lama untuk melakukannya. RPM juga menderita dari situs-situs seperti rpmfind di mana Anda akan menemukan 10+ paket yang tidak kompatibel untuk distribusi yang berbeda. Aptsepenuhnya menyembunyikan masalah ini untuk paket DEB karena semua paket terinstal dari sumber yang sama.

Menurut pendapat saya, zypperbenar-benar telah menutup kesenjangan aptdan tidak ada alasan untuk malu menggunakan distribusi berbasis RPM hari ini. Ini sama baiknya jika tidak lebih mudah digunakan dengan layanan build openSUSE yang tersedia untuk indeks paket yang sangat kompatibel.

Dari sudut pandang administrator sistem, saya telah menemukan beberapa perbedaan kecil, terutama pada set alat dpkg / rpm daripada format paket.

• dpkg-divertmemungkinkan untuk memiliki file Anda sendiri menggantikan file yang berasal dari sebuah paket. Ini bisa menjadi penyelamat ketika Anda memiliki program yang mencari file di /usratau /libdan tidak akan menerima /usr/localjawaban. Idenya telah diusulkan, tetapi sejauh yang saya tahu tidak diadopsi, dalam rpm.

• Ketika saya terakhir kali mengelola sistem berbasis rpm (yang diakui bertahun-tahun yang lalu, mungkin situasinya telah membaik), rpm akan selalu menimpa file konfigurasi yang dimodifikasi dan memindahkan kustomisasi saya ke *.rpmsave(IIRC). Ini telah membuat sistem saya tidak bisa di-boot setidaknya sekali. Dpkg bertanya kepada saya apa yang harus dilakukan, dengan menjaga kustomisasi saya sebagai default.

• Paket biner rpm dapat mendeklarasikan dependensi pada file daripada paket, yang memungkinkan kontrol yang lebih baik daripada paket deb.

• Anda tidak dapat menginstal paket versi N rpm pada sistem dengan versi N-1 dari alat rpm. Itu mungkin berlaku untuk dpkg juga, kecuali formatnya tidak sering berubah.

• Database dpkg terdiri dari file teks. Database rpm adalah biner. Ini membuat basis data dpkg mudah diselidiki dan diperbaiki. Di sisi lain, selama tidak ada yang salah, rpm bisa menjadi jauh lebih cepat (menginstal deb membutuhkan membaca ribuan file kecil).

• Sebuah paket deb menggunakan format standar ( ar, tar, gzip) sehingga Anda dapat memeriksa, dan tweak pinch) paket deb dengan mudah. Paket Rpm hampir tidak ramah.

RPM:

• 'Standar' (bukan karena tidak ada spesifikasi deb)
• Digunakan oleh banyak distribusi yang berbeda (tetapi paket dari satu tidak harus bekerja pada yang lain)
• IIRC memungkinkan dependensi pada file, tidak hanya pada paket

DEB:

• Popularitas semakin meningkat
• Mengizinkan rekomendasi dan saran (mungkin RPM yang lebih baru memungkinkannya juga)

Mungkin pertanyaan yang lebih penting adalah manajer paket (dpkg vs yum vs aptitude dll.) Daripada format paket (karena keduanya sebanding).

Seperti yang dikatakan oleh beberapa responden, format paket tertentu tidak terlalu unggul. Secara teknis, mereka mungkin kurang lebih sebanding. Dari sudut pandang saya banyak perbedaan, dan mengapa orang lebih suka satu daripada yang lain, harus dilakukan dengan:

• Filosofi desain paket asli dan target audiens
• Ukuran komunitas, dan dengan perluasan, kualitas dan kekayaan repositori

Filsafat:

Di dunia Ubuntu / Debian / Mint / ..., pengguna mengharapkan paket yang terinstal "hanya berfungsi" setelah diinstal. Ini berarti bahwa selama instalasi, paket-paket diharapkan untuk mengurus segala yang dibutuhkan untuk benar-benar membuatnya berjalan dengan baik, termasuk tetapi tidak terbatas pada:

• mengatur pekerjaan cron yang diperlukan atau opsional
• menyiapkan alternatif / alias
• mengatur skrip startup / shutdown
• termasuk semua file konfigurasi yang diperlukan dengan standar yang masuk akal
• menjaga versi lama perpustakaan dan menambahkan symlinks versi yang benar ke perpustakaan (.so's) untuk kompatibilitas
• dukungan bersih untuk binari multi-lengkungan (32 dan 64 bit) pada mesin yang sama dan seterusnya.

Di dunia rpm - memang ini adalah situasi beberapa tahun yang lalu, dan mungkin telah membaik sejak saat itu - saya mendapati diri saya harus menjalankan langkah-langkah tambahan (misalnya chkconfig, memungkinkan pekerjaan cron) untuk benar-benar membuat paket benar-benar berfungsi. Ini mungkin baik untuk sysadmin atau orang yang memiliki pengetahuan tentang Unix, tetapi itu membuat pengalaman pemula menderita. Perhatikan bahwa bukan karena format paket RPM itu sendiri mencegah hal ini terjadi, hanya saja banyak paket secara de-facto tidak "sepenuhnya selesai" dari sudut pandang seorang pemula.

Ukuran komunitas, partisipasi, dan kekayaan repositori:

Karena komunitas ubuntu / debian / mint / ... lebih besar, lebih banyak orang terlibat dalam pengemasan dan pengujian perangkat lunak. Saya menemukan kekayaan dan kualitas repositori lebih unggul. Di ubuntu saya jarang, jika sama sekali, perlu mengunduh sumber dan membangunnya. Ketika saya beralih dari Red Hat ke Ubuntu di rumah, repo khas RHEL memiliki ~ 3000 paket di dalamnya, sementara pada saat yang sama, ubuntu + universe + multiverse semuanya tersedia langsung dari cermin Canonical, memiliki ~ 30.000 paket (sekitar 10x). Sebagian besar paket yang saya cari dalam format RPM, tidak dapat diakses dengan mudah melalui pencarian dan klik pada manajer paket. Mereka membutuhkan pengalihan ke repositori alternatif, mencari situs web layanan rpmfind dll. Ini, dalam banyak kasus, daripada menyelesaikan masalah, merusak instalasi saya dengan gagal membatasi dependensi apa yang dapat atau tidak dapat ditingkatkan dengan benar. Saya terkena fenomena "ketergantungan neraka", seperti dijelaskan di atas oleh Shawn J. Goff.

Sebaliknya di Ubuntu / Debian saya menemukan bahwa saya hampir tidak perlu membangun dari sumber. Juga karena:

• Siklus rilis cepat Ubuntu (6 bulan)
• Adanya PPA yang sepenuhnya kompatibel yang bekerja di luar kotak
• Repositori sumber tunggal (semua dihosting oleh Canonical) tidak perlu mencari repo alternatif / pelengkap
• Pengalaman pengguna yang mulus dari klik untuk menjalankan

Saya tidak pernah harus berkompromi pada paket versi lama yang saya pedulikan, bahkan ketika mereka tidak dikelola oleh pengembang resmi (Canonical). Saya tidak pernah meninggalkan manajer paket GUI ramah favorit saya untuk melakukan pencarian yang mudah berdasarkan kata kunci, untuk menemukan dan menginstal paket apa pun yang saya inginkan. Juga, beberapa kali saya menginstal paket debian (non Canonical) di Ubuntu dan mereka bekerja dengan baik, meskipun kompatibilitas ini tidak dijamin secara resmi.

Perhatikan bahwa ini tidak dimaksudkan untuk memulai perang api, itu hanya berbagi pengalaman saya setelah menggunakan kedua dunia secara paralel selama beberapa tahun (bekerja vs rumah).

Saya pikir bias tidak berasal dari format paket, tetapi dari inkonsistensi yang dulu ada di repositori RedHat.

Kembali ketika RedHat adalah distribusi (sebelum zaman RHEL, Fedora, dan Fedora Core), orang-orang kadang-kadang menemukan diri mereka dalam "Neraka RPM" atau "Neraka ketergantungan". Ini terjadi ketika repositori akan berakhir dengan paket yang memiliki dependensi (beberapa lapisan, biasanya) yang saling eksklusif. Atau akan muncul ketika dua paket berbeda memiliki dua dependensi yang saling eksklusif. Ini adalah masalah dengan keadaan repositori, bukan dengan format paket. "RPM Hell" meninggalkan ketidaksukaan terhadap sistem RPM di antara beberapa populasi pengguna Linux yang telah terbakar oleh masalah.

Ada juga perbedaan "filosofis" di mana dalam paket Debian Anda dapat mengajukan pertanyaan dan dengan ini, memblokir proses instalasi. Sisi buruknya adalah beberapa paket akan memblokir pembaruan Anda hingga Anda membalas. Sisi baiknya adalah, juga sebagai perbedaan filosofis, pada sistem berbasis Debian, ketika sebuah paket diinstal, itu dikonfigurasikan (tidak selalu seperti yang Anda inginkan) dan berjalan. Bukan pada sistem berbasis Redhat di mana Anda perlu membuat / menyalin dari / usr / share / doc / * file konfigurasi templat / default.

Satu hal yang saya sukai tentang RPM adalah penambahan (terkini?) Delta RPM. Ini memungkinkan pembaruan yang lebih mudah, mengurangi bandwidth yang dibutuhkan.

DEB adalah file standar ar (dengan lebih banyak arsip standar di dalamnya), RPM adalah file biner "eksklusif". Saya pribadi berpikir yang pertama lebih nyaman.

Hanya dua hal yang dapat saya pikirkan di atas kepala saya. Keduanya sangat sebanding. Keduanya memiliki alat yang luar biasa untuk pengemasan. Saya tidak berpikir ada begitu banyak pahala untuk satu di atas yang lain atau sebaliknya.

OpenSUSE Build Service (OBS) dan zypper adalah beberapa alasan mengapa saya lebih suka RPM daripada deb dari sudut pandang pengemas dan pengguna. Zypper telah datang jauh dan cukup cepat. OBS, meskipun dapat menangani debs, sangat bagus dalam hal pengemasan rpms untuk berbagai platform seperti openSUSE, SLE, RHEL, centos, fedora, mandriva, dll.

Paket Debian dapat menyertakan ukuran yang diinstal , tetapi saya tidak percaya RPM memiliki bidang yang setara. Ini dapat dihitung berdasarkan file yang termasuk dalam paket, tetapi juga tidak dapat diandalkan karena tindakan yang dapat diambil dalam skrip instal pra / post instal.

Berikut ini adalah referensi yang cukup bagus untuk perbandingan beberapa fitur spesifik yang tersedia untuk setiap format kemasan tertentu: http://debian-br.sourceforge.net/txt/alien.htm (menurut server web, dokumen itu cukup lama : Terakhir Dimodifikasi: Sun, 15 Okt 2000 jadi ini mungkin bukan referensi terbaik.)

Untuk Paket Debian ada banyak skrip pembantu, manual kebijakan yang konsisten dan setidaknya satu cara untuk melakukan hampir semua hal. Dependensi ditangani dengan sangat baik dan dapat didefinisikan dalam granularitas yang sangat baik. Paket pembangunan kembali sangat mudah dengan paket debian dan didukung dengan baik oleh alat yang tersedia.

Tidak ada jawaban lain yang menyentuh bagaimana tiga perbedaan mendasar berikut memiliki konsekuensi nyata:

1. debfile pada dasarnya hanya ararsip yang berisi dua tarbal terkompresi
2. debpaket dan dpkgsistem menyimpan skrip pengelola Anda sebagai file terpisah
3. dpkgdan rpmjalankan skrip pengelola dalam urutan berbeda selama peningkatan.

Bersama-sama, perbedaan-perbedaan ini membuatnya lebih mudah bagi saya untuk memperbaiki masalah yang disebabkan oleh paket yang buruk, dan untuk membuat paket berperilaku seperti yang saya inginkan, pada debsistem berbasis daripada rpmsistem berbasis, baik sebagai administrator sistem dan sebagai pembuat paket. .

Karena # 1, jika saya perlu mengubah debfile, saya dapat dengan mudah membuka pop, membuat perubahan yang saya inginkan, dan mengemasnya kembali, menggunakan alat standar yang ada pada sebagian besar sistem .

Ini termasuk mengubah / menambah / menghapus dependensi, atau file paket apa pun, atau skrip pengelola apa pun, atau mengubah versi atau nama paket.

Karena # 2, jika ada masalah dalam skrip "hapus" yang diinstal oleh paket yang sudah diinstal , saya bisa memperbaikinya dengan menggunakan perangkat standar yang ada di sistem apa pun .

Karena # 3, saya dapat melakukan beberapa perbaikan tersebut hanya dengan merilis versi baru dari paket saya, karena selama peningkatan, dpkgjalankan skrip "pra-instal" versi baru paket sebelum skrip "post-remove" dari versi lama.

Ini berarti bahwa area permukaan untuk melanggar "prinsip pemulihan" dalam debpaket lebih kecil : lebih banyak kesalahan dalam versi sebelumnya dari paket dapat dipulihkan dari dengan versi baru.

Dan karena memodifikasi paket sangat mudah - biola yang sebenarnya khusus untuk paket dan pengetahuan kecil - dapat diakses oleh lebih banyak orang dan membutuhkan waktu dan usaha lebih sedikit, dengan debfile.