it-swarm-id.com

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?

173
Evan

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

Di dunia RPM, semua paket Anda (RPM yang Anda kelola) terletak di sesuatu seperti ~/rpmbuild. Di bawahnya, ada direktori SPEC untuk file-spec Anda, direktori SOURCES untuk tarball sumber, RPMS dan SRPMS direktori untuk meletakkan RPM yang baru dibuat dan SRPM menjadi, dan beberapa hal lain yang tidak relevan sekarang.

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

Sekarang, secara pribadi, saya suka fakta bahwa semuanya masuk ke file spesifikasi, dan bahwa file spesifikasi adalah entitas yang terpisah dari tarball sumber, tapi saya tidak terlalu antusias untuk 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 tepat sama 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, itu sedikit lebih diterima untuk membawa tambalan dalam paket yang belum (belum) hulu. Di dunia RPM (setidaknya di antara turunan Red Hat) ini disukai. Lihat "FedoraProject: Tetap dekat dengan proyek-proyek hulu" .

Juga, Debian memiliki sejumlah besar skrip yang dapat mengotomatisasi sebagian besar pembuatan paket. Misalnya, membuat paket - sederhana - dari setuptool'ed Python, semudah membuat beberapa file meta-data dan menjalankan debuild. Yang mengatakan, spec-file untuk paket semacam itu dalam format RPM akan sangat pendek dan di dunia RPM, juga, ada banyak hal yang diotomatisasi akhir-akhir ini.

87
wzzrd

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

Dari sudut pandang pengguna, tidak ada banyak perbedaan dalam alat ini. Format RPM dan DEB keduanya hanya arsip file, dengan beberapa metadata yang melekat padanya. Keduanya sama-sama misterius, memiliki jalur instalasi hardcoded (yuck!) Dan hanya berbeda dalam detail halus. Keduanya dpkg -i dan rpm -i tidak memiliki cara untuk mengetahui 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-get telah unggul dalam memproses sejumlah besar metadata sangat cepat sementara yum akan membutuhkan 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. Apt menyembunyikan masalah ini untuk paket DEB karena semua paket terinstal dari sumber yang sama.

Menurut pendapat saya, zypper benar-benar telah menutup celah untuk apt dan tidak ada alasan untuk malu menggunakan distribusi berbasis RPM hari ini. Ini sama baiknya jika tidak lebih mudah digunakan dengan layanan build openSUSE untuk indeks paket kompatibel yang besar.

97
vdboor

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

  • dpkg-divert memungkinkan untuk memiliki file Anda sendiri menggantikan file yang berasal dari sebuah paket. Ini bisa menjadi penyelamat ketika Anda memiliki program yang mencari file di /usr atau /lib dan tidak akan mengambil /usr/local untuk jawaban. Idenya telah diusulkan, tetapi sejauh yang saya tahu tidak diadopsi, dalam rpm.

  • Ketika saya terakhir kali mengelola sistem berbasis rpm (yang memang diakui bertahun-tahun lalu, mungkin situasinya telah membaik), rpm akan selalu menimpa file konfigurasi yang dimodifikasi dan memindahkan penyesuaian 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. Basis data 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).

  • Paket deb menggunakan format standar (ar, tar, gzip) sehingga Anda dapat memeriksa, dan dalam Tweak cubit) 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:

  • Semakin populer
  • 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).

19
Maciej Piechotka

Seperti yang dikatakan beberapa responden, format paket tidak terlalu banyak jelas lebih 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 semua yang diperlukan 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) untuk kompatibilitas
  • dukungan bersih untuk binari multi-Arch (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 (mis. 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 "selesai" dari perspektif seorang pemula.

kuran 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 mirror Canonical apa pun, memiliki ~ 30.000 paket (kira-kira 10x). Sebagian besar paket yang saya cari dalam format RPM, tidak dapat diakses dengan mudah melalui pencarian dan klik pada manajer paket. Mereka perlu beralih ke repositori alternatif, mencari situs web layanan rpmfind dll. Ini, dalam kebanyakan 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)
  • Keberadaan sepenuhnya kompatibel PPA yang berfungsi 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).

15
arielf

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 kadang-kadang akan 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 untuk sistem RPM di antara beberapa populasi pengguna Linux yang telah terbakar oleh masalah.

12
Shawn J. Goff

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 upgrade Anda sampai 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.

8
Luc Stepniewski

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 ar standar (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 sangat baik untuk pengemasan. Saya tidak berpikir ada begitu banyak pahala untuk satu di atas yang lain atau sebaliknya.

6
johansson

Paket Debian dapat menyertakan kuran terpasang , tapi saya tidak percaya RPM memiliki bidang yang setara. Itu 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 web server, dokumen itu cukup lama: Terakhir Dimodifikasi: Sun, 15 Okt 2000 jadi ini mungkin bukan referensi terbaik.)

5
Mike Gray

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, benar-benar bagus dalam hal pengemasan rpms untuk berbagai platform seperti openSUSE, SLE, RHEL, centos, Fedora, mandriva, dll.

5
decriptor

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

  1. deb file pada dasarnya hanya ar arsip yang berisi dua tarbal terkompresi
  2. deb paket dan sistem dpkg menyimpan skrip pengelola Anda sebagai file terpisah
  3. dpkg dan rpm menjalankan skrip pengelola dalam urutan yang berbeda selama peningkatan.

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

Karena # 1, jika saya perlu mengubah file deb, saya dapat membukanya secara sepele, membuat perubahan yang saya inginkan, dan mengemasnya kembali, menggunakan alat standar yang ada pada kebanyakan sistem =.

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

Karena # 2, jika ada masalah dalam skrip "hapus" yang diinstal oleh sebuah paket yang sudah diinstal, saya dapat memperbaikinya secara sepele, menggunakan alat standar yang ada pada sistem apa pun.

Karena # 3, saya dapat melakukan beberapa perbaikan hanya dengan merilis versi baru dari paket saya, karena selama upgrade, dpkg menjalankan skrip "pra-instal" dari versi baru paket sebelumnya skrip "post-remove" dari versi lama.

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

Dan karena memodifikasi paket itu 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 file deb.

4
mtraceur

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 re-building sangat mudah dengan paket debian dan didukung dengan baik oleh alat yang tersedia.

4
tex

Cari Google untuk mencari

  1. paket duplikat rpm
  2. paket duplikat dpkg

Baca halaman yang kembali. Sangat mengatakan bahwa Anda dapat memiliki database RPM yang berantakan dengan paket duplikat di dalamnya sementara tidak ada kasus seperti itu terjadi pada dpkg.

2
user2472