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?
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.
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.
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:
DEB:
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).
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:
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:
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:
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).
Ö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ı.
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.
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.
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.)
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.
Diğer cevapların hiçbiri aşağıdaki üç temel farklılığın gerçek sonuçları nasıl etkilediğine değmez:
debdosyaları temelde iki sıkıştırılmış tarball içeren
ararşividir
debpaketleri ve
dpkgsistemi bakımcı komut dosyalarınızı ayrı dosyalar olarak saklar
dpkgve
rpmyü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.
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.
Google'da ara
Geri gelen sayfaları okuyun. Çok dpkg ile böyle bir durumda olurken içinde yinelenen paketleri ile berbat bir RPM veritabanı olabilir söylemek.