it-swarm-tr.com

Deb / rpm vs artıları / eksileri nelerdir?

Hangi nedenle olursa olsun, RPM tabanlı dağıtımları her zaman kullandım (Fedora, Centos ve şu anda openSUSE). Sık sık deb'in rpm'den daha iyi olduğunu belirttiğini duydum, ancak neden sorulduğunda, asla tutarlı bir cevap alamadım (genellikle bunun yerine gayretli bir şekilde ve bol miktarda tükürük elde edin).

Bazı tarihsel nedenler olabileceğini anlıyorum, ancak iki farklı paketleme yöntemini kullanan modern dağıtımlar için, biri diğerine karşı teknik (veya diğer) değerleri verebilir mi?

173
Evan

Bir paket bakımcısı için ana fark (Debian lingo'da 'geliştirici' olacağını düşünüyorum) paket meta-veri ve beraberindeki komut dosyalarının bir araya gelmesidir.

RPM dünyasında, tüm paketleriniz (bakımını yaptığınız RPM'ler) ~/rpmbuild. Altında, spec dosyalarınız için SPEC dizini, kaynak tarball'lar için bir SOURCES dizini, yeni oluşturulan RPM'ler koymak için RPMS ve SRPMS dizinleri ve SRPM'ler ve şu anda alakalı olmayan diğer bazı şeyler.

RPM'nin nasıl oluşturulacağıyla ilgili her şey spec dosyasındadır: hangi yamalar uygulanacak, olası ön ve son komut dosyaları , meta veri, changelog, her şey. Tüm kaynak tarball'lar ve paketlerinizin tüm yamaları SOURCES içindedir.

Şimdi, kişisel olarak, her şeyin spec dosyasına girmesini ve spec dosyasının kaynak tarball'dan ayrı bir varlık olması gerçeğini seviyorum, ancak hakkında aşırı hevesli değilim SOURCES içindeki tüm kaynaklar. IMHO, SOURCES oldukça hızlı bir şekilde karışıyor ve orada ne olduğunu takip etme eğilimindesiniz. Ancak görüşler farklıdır.

RPM'ler için, zaman damgasına kadar tam yukarı akış projesinin serbest bıraktığı aynı tarball'ı kullanmak önemlidir. Genellikle, bu kuralın istisnası yoktur. Debian paketleri de yukarı akışla aynı tarball gerektirir, ancak Debian politikası bazı tarball'ların yeniden paketlenmesini gerektirir (teşekkürler, Umang).

Debian paketleri farklı bir yaklaşım izlemektedir. (Burada herhangi bir hata affet: RPM ile olduğum deb's çok daha az deneyimli.) Debian paketleri geliştirme dosyaları paket başına bir dizinde yer almaktadır.

Bu yaklaşım hakkında sevdiğim (her şey tek bir dizinde yer alıyor).

Debian dünyasında, yamaları (henüz) yukarı doğru olmayan bir pakette taşımak biraz daha kabul edilir. RPM dünyasında (en azından Red Hat türevleri arasında) bu kaşlarını çattı. Bakınız "FedoraProject: Akış yukarı projelere yakın kalmak" .

Ayrıca, Debian'ın bir paket oluşturmanın büyük bir bölümünü otomatikleştirebilen çok sayıda komut dosyası vardır. Örneğin, bir setuptool'ed Python) programının bir - basit - paketi oluşturmak, birkaç meta veri dosyası oluşturmak ve debuild çalıştırmak kadar basittir. RPM formatında böyle bir paketin spec dosyası oldukça kısa olurdu ve RPM dünyasında da, bu günlerde otomatikleştirilmiş birçok şey var.

87
wzzrd

Birçok insan yükleme yazılımını apt-get ila rpm -i ve bu nedenle DEB'yi daha iyi söyleyin. Ancak bunun DEB dosya biçimiyle ilgisi yoktur. Gerçek karşılaştırma dpkg ile rpm ve aptitude/apt-* vs zypper/yum.

Bir kullanıcının bakış açısından, bu araçlarda fazla bir fark yoktur. RPM ve DEB biçimlerinin her ikisi de yalnızca arşiv dosyalarıdır ve bazı meta veriler eklenmiştir. Her ikisi de eşit derecede gizlidir, sabit kodlu kurulum yollarına (yuck!) Sahiptir ve sadece ince detaylarda farklılık gösterir. Her ikisi de dpkg -i ve rpm -i, komut satırında belirtilmeleri dışında bağımlılıkların nasıl kurulacağını anlamanın hiçbir yolu yoktur.

Bu araçların üstünde, apt-... veya zypper/yum. Bu araçlar depoları indirir, tüm meta verileri izler ve bağımlılıkların indirilmesini otomatikleştirir. Her bir paketin son kurulumu düşük seviyeli aletlere teslim edilir.

Uzun zamandır, apt-get, muazzam miktarda meta veriyi gerçekten hızlı işlemede üstündür, yum bunu yapmak için zaman alacaktır. RPM ayrıca farklı dağıtımlar için 10'dan fazla uyumsuz paket bulabileceğiniz rpmfind gibi sitelerden de muzdaripti. Apt, tüm paketler aynı kaynaktan yüklendiği için DEB paketleri için bu sorunu tamamen gizledi.

Kanımca zypper, apt ile olan boşluğu gerçekten kapattı ve bugünlerde RPM tabanlı bir dağıtım kullanmaktan utanmak için hiçbir neden yok. Büyük bir uyumlu paket dizini için eldeki openSUSE derleme hizmetiyle kullanımı daha kolay olmasa da iyidir.

97
vdboor

Sistem yöneticisinin bakış açısından, paket formatı yerine dpkg/rpm araç setinde birkaç küçük fark buldum.

  • dpkg-divert, Kendi dosyanızın bir paketten gelen dosyayı değiştirmesini sağlar. /usr Veya /lib İçinde dosya arayan bir programınız olduğunda ve /usr/local Yanıt almazsanız cankurtaran olabilir. Fikir önerildi, ancak benim söyleyebildiğim kadarıyla, rpm'de kabul edilmedi.

  • En son rpm tabanlı sistemleri yönettiğimde (kabul edilen yıllar önce belki de durum iyileşti), rpm her zaman değiştirilmiş yapılandırma dosyalarının üzerine yazacak ve özelleştirmelerimi *.rpmsave (IIRC) haline getirecekti. Bu, sistemimi en az bir kez önyüklenemez hale getirdi. Dpkg, özelleştirmelerimi varsayılan olarak koruyarak bana ne yapacağımı soruyor.

  • Bir rpm ikili paketi, paketlerden ziyade dosyalara bağımlılıklar bildirebilir ve bu da bir deb paketinden daha iyi kontrol sağlar.

  • RPM araçlarının N-1 sürümüne sahip bir sisteme sürüm N rpm paketi yükleyemezsiniz. Biçim sık sık değişmediği sürece, bu dpkg için de geçerli olabilir.

  • Dpkg veritabanı metin dosyalarından oluşur. Rpm veritabanı ikilidir. Bu, dpkg veritabanının araştırılmasını ve onarılmasını kolaylaştırır. Öte yandan, hiçbir şey yanlış gitmediği sürece, rpm çok daha hızlı olabilir (bir deb yüklemek binlerce küçük dosyanın okunmasını gerektirir).

  • Bir deb paketi standart formatları (ar, tar, gzip) kullanır, böylece deb paketlerini kolayca inceleyebilirsiniz. RPM paketleri neredeyse dost değil.

RPM:

  • 'Standardized' (bir deb spesifikasyonu olmadığı için)
  • Birçok farklı dağıtım tarafından kullanılır (ancak birinden paketler diğerinde çalışmayabilir)
  • IIRC dosyalara bağımlılık sağlar, sadece paketlere değil

DEB:

  • Büyüyen popülerlik
  • Önerilere ve önerilere izin verir (muhtemelen daha yeni RPM de buna izin verir)

Muhtemelen en önemli soru, paket formatı yerine (her ikisi de karşılaştırılabilir olduğu gibi) paket yöneticisidir (dpkg vs. yum vs. yetenek).

19
Maciej Piechotka

Birçok yanıtlayıcının söylediği gibi, belirli bir paket biçiminin açıkça üstün olduğu pek fazla değildir. Teknik olarak, az çok karşılaştırılabilir olabilirler. Benim bakış açımdan pek çok farklılık ve insanların neden birini diğerinden daha fazla tercih ettikleri:

  • Orijinal ambalaj tasarımı felsefesi ve hedef kitle
  • Topluluk büyüklüğü ve buna bağlı olarak depoların kalitesi ve zenginliği

Felsefe:

Ubuntu/Debian/Mint/... dünyasında, kullanıcılar yüklendikten sonra kurulu paketin "sadece çalışmasını" bekler. Bu, kurulum sırasında, paketlerin aşağıdakileri içeren ancak bunlarla sınırlı olmayan, gerçekten iyi çalışmasını sağlamak için gereken her şeye dikkat etmeleri gerektiği anlamına gelir:

  • gerekli veya isteğe bağlı cron işlerini ayarlama
  • alternatif/takma ad oluşturma
  • başlatma/kapatma komut dosyalarını ayarlama
  • gerekli tüm varsayılan yapılandırma dosyaları dahil olmak üzere
  • eski kitaplık sürümlerini tutma ve geriye dönük uyumluluk için kitaplıklara (.so) doğru sürümlendirilmiş simgeleri ekleme
  • aynı makinede çoklu Arch (32 ve 64 bit) ikili dosyaları için temiz destek vb.

RPM dünyasında - kuşkusuz bu birkaç yıl önceki durumdu ve o zamandan beri iyileşmiş olabilir - kendimi paketleri gerçekten işe yaratacak ek adımlar (örneğin chkconfig, cron işlerini etkinleştirme) yapmak zorunda buldum. Bu sistem yöneticileri veya Unix hakkında bilgili insanlar için uygun olabilir, ancak acemi deneyimleri acı çeker. RPM paket biçiminin kendisinin bunun olmasını engellemediğini, sadece birçok paketin fiili olmadığını "tamamen bitti" bir acemi bakış açısı.

Toplulukların büyüklüğü, katılımı ve depoların zenginliği:

Ubuntu/debian/nane/... topluluğu daha büyük olduğundan, paketleme ve test yazılımına daha fazla kişi katılmaktadır. Depoların zenginliğinin ve kalitesinin üstün olduğunu gördüm. Ubuntu'da nadiren, eğer hiç değilse, kaynak indirip ondan derlemeye ihtiyacım var. Red Hat'tan evde Ubuntu'ya geçtiğimde, tipik RHEL repoda ~ 3000 paket vardı, aynı zamanda ubuntu + evren + doğrudan herhangi bir Canonical aynadan mevcut tüm çoklu evrenlerde ~ 30.000 paket vardı (kabaca 10x). RPM biçiminde aradığım paketlerin çoğuna, basit arama ve paket yöneticisini tıklatarak kolayca erişilemedi. Alternatif depolara geçmeleri, rpmfind servis web sitesinde vb. Arama yapmaları gerekiyordu. Bu, çoğu durumda, sorunu çözmek yerine, hangi bağımlılıkların doğru bir şekilde yükseltilemediğini veya yükseltilemediğini kısıtlayarak kurulumumu bozdu. Yukarıda Shawn J. Goff tarafından tarif edildiği gibi "bağımlılık cehennemi" fenomenine çarptım.

Bunun aksine Ubuntu/Debian'da neredeyse hiç kaynaktan inşa etmem gerektiğini fark ettim. Ayrıca:

  • Ubuntu hızlı (6 aylık) sürüm döngüsü
  • Kutusundan çıkan tam uyumlu PPA'ların varlığı
  • Tek kaynak havuzları (tümü Canonical tarafından barındırılır) alternatif/tamamlayıcı depolar aramaya gerek yoktur
  • Tıklamadan çalıştırmaya sorunsuz kullanıcı deneyimi

Resmi (Canonical) geliştiriciler tarafından bakılmasalar bile, ilgilendiğim paketlerin eski sürümlerinden asla ödün vermek zorunda kalmadım. İstediğim herhangi bir paketi bulmak ve yüklemek için, anahtar kelime ile uygun bir arama yapmak için en sevdiğim dostu GUI paket yöneticimi bırakmak zorunda kalmadım. Ayrıca, birkaç kez Ubuntu'ya debian (Canonical olmayan) paketleri yükledim ve bu uyumluluğun resmi olarak garanti edilmemesine rağmen gayet iyi çalıştılar.

Bunun bir alev savaşı başlatmak için tasarlanmadığını, sadece her iki dünyayı da birkaç yıl boyunca paralel olarak kullandığım deneyimlerimi paylaştığımı unutmayın (iş ve ev).

15
arielf

Önyargıların paket biçiminden değil, RedHat'ın depolarında var olan tutarsızlıklardan geldiğini düşünüyorum.

RedHat bir dağıtım olduğunda (RHEL, Fedora ve Fedora Core günlerinden önce), insanlar bazen kendilerini "RPM Cehenneminde" veya "bağımlılık Cehenneminde" bulurlardı. Bu, bir havuz, karşılıklı olarak münhasır olan bir bağımlılığa (genellikle birkaç katman derin,) sahip bir paketle sonuçlandığında meydana geldi. Veya iki farklı paketin birbirini dışlayan iki bağımlılığı olduğunda ortaya çıkar. Bu, paketin biçiminde değil, deponun durumuyla ilgili bir sorundu. "RPM Cehennem", sorun tarafından yakılan bazı Linux kullanıcı nüfusu arasında RPM sistemleri için bir hoşnutsuzluk bıraktı.

12
Shawn J. Goff

Debian paketlerinde soru sorabileceğiniz ve bu sayede kurulum sürecini engelleyebileceğiniz "felsefi" bir fark da vardır. Bunun kötü tarafı, bazı paketlerin siz yanıtlayana kadar yükseltmelerinizi engellemesidir. Bunun iyi tarafı, felsefi bir fark olarak, Debian tabanlı sistemlerde, bir paket kurulduğunda, yapılandırılır (her zaman istediğiniz gibi değil) ve çalışır. Varsayılan/şablon yapılandırma dosyasını/usr/share/doc/* oluşturmanız/kopyalamanız gereken Redhat tabanlı sistemlerde değil.

8
Luc Stepniewski

RPM'ler hakkında sevdiğim bir şey delta RPM'lerin (son zamanlarda?) Eklenmesi. Bu, daha kolay güncelleme yapılmasını sağlar ve gerekli olan bant genişliğini azaltır.

DEB'ler standart ar dosyalarıdır (içinde daha fazla standart arşiv bulunur), RPM'ler "tescilli" ikili dosyalardır. Şahsen eski daha uygun olduğunu düşünüyorum.

Kafamın üstünden düşünebileceğim sadece iki şey. Her ikisi de çok benzer. Her ikisi de ambalaj için mükemmel araçlara sahiptir. Biri için diğerinin üzerinde çok fazla değer olduğunu düşünmüyorum ya da tam tersi.

6
johansson

Debian paketleri bir kurulu boyut içerebilir, ancak RPM'lerin eşdeğer bir alana sahip olduğuna inanmıyorum. Pakete dahil edilen dosyalara göre hesaplanabilir, ancak yükleme öncesi/sonrası komut dosyalarında yapılabilecek eylemler nedeniyle de güvenilemez.

Her bir özel ambalaj formatı için mevcut bazı belirli özelliklerin karşılaştırılması için oldukça iyi bir referans: http://debian-br.sourceforge.net/txt/alien.htm (web'e göre sunucu, bu belge oldukça eski: Son Değiştirme Tarihi: 15 Ekim 2000 Pazar bu en iyi referans olmayabilir.)

5
Mike Gray

OpenSUSE Yapı Hizmeti (OBS) ve zypper, bir paketleyici ve kullanıcı açısından debiden RPM'yi tercih etmemin birkaç nedeni. Zypper uzun bir yol kat etti ve oldukça hızlı. OBS, ele geçirebilmesine rağmen, openSUSE, SLE, RHEL, centos, Fedora, mandriva, vb.

5
decriptor

Diğer cevapların hiçbiri aşağıdaki üç temel farklılığın gerçek sonuçları nasıl etkilediğine değmez:

  1. deb dosyaları temelde iki sıkıştırılmış tarball içeren ar arşividir
  2. deb paketleri ve dpkg sistemi bakımcı komut dosyalarınızı ayrı dosyalar olarak saklar
  3. dpkg ve rpm yükseltme sırasında bakım dosyası komut dosyalarını farklı bir sırayla çalıştırın.

Birlikte, bu farklılıklar çok daha kolay benim için kötü paketlerin neden olduğu sorunları çözmeyi ve paketlerin ihtiyaç duyduğum şekilde davranmasını sağlamak için deb tabanlı sistemlerde rpm tabanlı sistemler, her ikisi de sistem yöneticisi olarak ve paketleyici olarak.

# 1 nedeniyle, bir deb dosyasını değiştirmeniz gerekirse, önemsizce açabilir, istediğim değişiklikleri yapabilir ve yeniden paketleyebilirim, çoğu sistemde bulunan standart araçları kullanarak =.

Bu, herhangi bir bağımlılığın veya paket dosyalarının veya bakımcı komut dosyalarının herhangi birinin değiştirilmesini/eklenmesini/kaldırılmasını veya paket sürümünün veya adının değiştirilmesini içerir.

# 2 nedeniyle, bir paket tarafından yüklenen "kaldır" komut dosyalarında bir sorun varsa zaten yüklü, önemsiz bir şekilde düzeltebilirim, herhangi bir sistemde var olan standart araçları kullanarak.

# 3 nedeniyle, bu düzeltmelerden bazılarını yalnızca paketimin yeni bir sürümünü yayınlayarak yapabilirim, çünkü yükseltme sırasında dpkg paketin yeni sürümünün "ön yükleme" komut dosyasını çalıştırır önce eski sürümün "post-remove" betiği.

Bu, "kurtarılabilirlik ilkesini" ihlal eden yüzey alanının deb paketlerinde daha küçük olduğu anlamına gelir: paketin önceki bir sürümünde daha fazla hata yeni bir sürümle kurtarılabilir.

Ve paketi değiştirmek çok kolay olduğu için - gerçek pakete özgü uğraş ve bilgi yükü küçüktür - deb dosyalarıyla daha fazla kişi tarafından erişilebilir ve daha az zaman ve çaba gerektirir.

4
mtraceur

Debian Paketleri için çok sayıda yardımcı komut dosyası, tutarlı bir politika kılavuzu ve hemen hemen her şeyi yapmanın en az bir yolu vardır. Bağımlılıklar çok iyi ele alınır ve çok iyi bir ayrıntı düzeyinde tanımlanabilir. Debian paketleri ile paketleri yeniden oluşturmak çok kolay ve mevcut araçlarla iyi destekleniyor.

4
tex

Google'da ara

  1. rpm yinelenen paketler
  2. dpkg yinelenen paketler

Geri gelen sayfaları okuyun. Çok dpkg ile böyle bir durumda olurken içinde yinelenen paketleri ile berbat bir RPM veritabanı olabilir söylemek.

2
user2472