Her ne sebeple olursa olsun, her zaman RPM tabanlı dağıtımları kullandım (Fedora, Centos ve şu anda openSUSE). Sık sık debinin rpm'den daha iyi olduğunu söylediğini sık sık duydum, ancak neden sorulduğunda tutarlı bir cevap alamadım (genellikle bunun yerine bazı kıskançlık ve aşırı miktarda tükürük elde et).
Bazı tarihsel nedenlerin olabileceğini anlıyorum, ancak iki farklı paketleme yöntemini kullanan modern dağıtımlar için, biri diğerinin teknik (veya diğer) değerlerini verebilir mi?
Yanıtlar:
Bir paket sorumlusu için ana fark (bence Debian lingo'da 'geliştirici' olur) paket meta-veri ve beraberindeki komut dosyalarının bir araya gelme şeklidir.
RPM dünyasında, tüm paketleriniz (sürdürdüğünüz RPM'ler) benzeri bir yerde bulunur ~/rpmbuild. Altında, SPECspec dosyalarınız SOURCESiçin bir dizin, kaynak hedefleri için bir dizin RPMSve SRPMSyeni oluşturulan RPM'leri ve SRPM'leri içine koyacak dizinler ve şimdi ilgili olmayan diğer şeyler var.
RPM'nin nasıl oluşturulacağıyla ilgili olan her şey spec-file dosyasındadır: hangi yamalar uygulanacak, olası senaryo öncesi ve sonrası, meta-data, changelog, her şey. Tüm kaynak tarball'lar ve tüm paketlerinizdeki yamalar SOURCES'tedir.
Şimdi, şahsen, her şeyin spec dosyasına girmesi ve spec dosyasının kaynak tarball'dan ayrı bir varlık olması hoşuma gidiyor, ancak SOURCES'te tüm kaynaklara sahip olmak konusunda fazlasıyla hevesli değilim . IMHO, SOURCES oldukça hızlı bir şekilde darmadağın olur ve orada ne olduğunu takip etme eğilimindedir. Ancak, görüşler farklıdır.
RPM'ler için kullanmak önemlidir kesin timestamp kadar biri olarak memba proje bültenleri aynı Tarball'ı. Genel olarak, bu kuralın istisnası yoktur. Debian paketleri ayrıca bazı tarball'ların yeniden paketlenmesini gerektiriyor, ancak Debian politikası bazı tarball'ların yeniden paketlenmesini istiyor (teşekkürler, Umang).
Debian paketleri farklı bir yaklaşım benimsiyor. (Buradaki hataları affedin: deb'lerde RPM'lerde bulunduğumdan daha az deneyimliyim.) Debian paketlerinin geliştirme dosyaları, paket başına bir dizinde bulunuyor.
Bu yaklaşım hakkında sevdiğim şey, her şeyin tek bir dizinde bulunması.
Debian dünyasında (henüz) yukarı akışta olmayan bir pakette yamaları taşımak biraz daha kabul edilir. RPM dünyasında (en azından Red Hat türevleri arasında) bu üzerine kaşlarını çattı. Bkz. "FedoraProject: Yukarı akıştaki projelere yakın kalmak" .
Ayrıca, Debian, paket oluşturmanın büyük bir bölümünü otomatikleştirebilen çok sayıda komut dosyasına sahiptir. Örneğin, bir setuptool'ed Python programının bir - basit - paketini oluşturmak, birkaç meta-veri dosyası oluşturmak ve çalıştırmak kadar basittir debuild. Bu, RPM formatında böyle bir paket için spec dosyası oldukça kısa olacağını ve RPM dünyasında da, bugünlerde otomatikleştirilmiş bir çok şey var dedi.
.diff.gzya da içinde kalır .debian.tar.gz, ancak kaynak paket çıkartıldığında debiandizin kaynak ağacının içindedir. BTW: Politika yeniden paketleme gerektirmediğinde, tarball'ın MD5'i upstream tarball'ınkiyle eşleşmelidir. Ayrıca, açıklığa kavuşturmak için, bakım sağlayıcımı akış yukarı kaynağa yapılan yamalar debian dizininde (kaynak formatı 3.0) ve .diff.gz(format 1.0) saklanır .
Birçok insan ile yazılım yüklemeden karşılaştırın apt-getiçin rpm -ive bu nedenle daha iyi DEB derler. Ancak bunun DEB dosya formatıyla bir ilgisi yok. Gerçek karşılaştırma dpkgvs rpmve aptitude/ apt-*vs zypper/ dir yum.
Bir kullanıcının bakış açısından, bu araçlarda pek bir fark yoktur. RPM ve DEB formatları hem sadece arşiv dosyalarıdır hem de bazı meta veriler bunlara eklenmiştir. Her ikisi de eşit şekilde yaylıdır, kodlanmış kurulum yollarına (yuck!) Sahiptir ve sadece ince detaylarda farklılık gösterir. Her ikisi de dpkg -ive rpm -ikomut satırında belirtilmediği sürece bağımlılıkların nasıl kurulacağını çözmenin bir yolu yoktur.
Bu araçların üzerine, şeklinde depo yönetimi var apt-...ya 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 verilir.
Uzun zamandır, apt-getçok büyük miktarlarda meta veriyi işlemede çok daha hızlı davranıyordu yum. Ayrıca RPM, farklı dağıtımlar için 10'dan fazla uyumsuz paket bulabileceğiniz rpmfind gibi sitelerden de zarar gördü. AptDEB paketleri için bu sorunu tamamen sakladı çünkü tüm paketler aynı kaynaktan kuruldu.
Benim düşünceme göre zypper, gerçekten açığı kapattı ve aptbu günlerde RPM tabanlı bir dağıtım kullanmaktan utanmak için hiçbir neden yok. Çok büyük bir uyumlu paket endeksi için eldeki openSUSE build servisi ile kullanımı kolay değilse de iyidir.
Bir sistem yöneticisinin bakış açısından, çoğunlukla paket biçiminden ziyade dpkg / rpm aracında bazı küçük farklar buldum.
dpkg-divertkendi dosyanızın bir paketten gelen dosyayı değiştirmesini mümkün kılar. Eğer bir dosyayı arar bir programa sahip zaman bir cankurtaran olabilir /usrOr /libve almayacağız /usr/localbir cevap. Bu fikir öne sürüldü, ancak söyleyebileceğim kadarıyla, rpm cinsinden.
En son rpm tabanlı sistemleri yönettiğimde (kuşkusuz yıllar önceydi, belki durum düzeldi), rpm her zaman değiştirilmiş yapılandırma dosyalarının üzerine yazar ve özelleştirmelerimi *.rpmsave(IIRC) içine taşır . Bu, sistemimi en az bir kez engellenemez hale getirdi. Dpkg, özelleştirmelerimi varsayılan olarak koruyarak ne yapacağımı soruyor.
Bir rpm ikili paketi, paketlerden ziyade dosyalara olan bağımlılığı bildirebilir, bu da bir deb paketinden daha iyi kontrol yapılmasını sağlar.
Bir sürüm N rpm paketini, rpm araçlarının N-1 sürümü olan bir sisteme yükleyemezsiniz. Bu, dpkg için de geçerli olabilir, ancak format çok sık değişmiyor.
Dpkg veritabanı metin dosyalarından oluşmaktadır. 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üklemesi binlerce küçük dosyayı okumayı gerektirir).
Bir deb paketi standart formatları ( ar,, ) kullanır tar, gzipböylece deb paketlerini kolayca inceleyebilirsiniz ve çimdik dedikodunuz. Rpm paketleri neredeyse kolay değil.
*.rpmnewGörünüşe göre, değiştirilmiş olanı gizlemek yerine yeni yapılandırma dosyasını kaydeder - en azından openSUSE'de.
rpm2cpio.sheğimli olanlar için de var .
debhatırlıyorum biçimi ne zaman data.tar.gzoldu data.tar.xzhangi yaşlı gelin dpkgyeni paketler açmak mümkün durdurdu.
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).
Bazı cevaplayıcıların söylediği gibi, belirli bir paket formatının açıkça üstün olması o kadar da değildir . Teknik olarak, daha fazla veya daha az karşılaştırılabilir olabilirler. Benim bakış açıma göre, birçok farklılık ve neden insanların birbirini tercih ettikleri ile ilgili olmak zorunda:
Felsefe:
Ubuntu / Debian / Mint / ... dünyasında, kullanıcılar yüklü paketin yüklendikten sonra "sadece çalışmasını" bekler. Bu, kurulum sırasında paketlerin aşağıdakiler dahil ancak bunlarla sınırlı olmamak üzere, gerçekten iyi çalışmasını sağlamak için gereken her şeye dikkat etmesi gerektiği anlamına gelir:
Devir / dakika dünyasında - kuşkusuz bu birkaç yıl önceki durumdu ve o zamandan beri iyileşmiş olabilir - kendimi paketlerin gerçekten çalışmasını sağlamak için ek adımlar (örn. Chkconfig, cron işlerini mümkün kılan) yapmak zorunda kaldım. Bu, sysadmins veya Unix hakkında bilgili olan insanlar için uygun olabilir, ancak acemi deneyimlerin acı çekmesine neden olur. RPM paket formatının kendisinin bunun olmasını engellemediğini, sadece pek çok paketin yeni başlayanların bakış açısından "tamamen yapılmadığını" söylediğine dikkat edin.
Topluluk büyüklüğü, katılım ve depoların zenginliği:
Ubuntu / debian / nane / ... topluluğu daha büyük olduğundan, ambalajlama ve test yazılımına daha fazla insan katılmaktadır. Depoların zenginliğini ve kalitesini üstün buldum. Ubuntu'da nadiren, kaynak indirme ve ondan derleme yapmam gerekecek. Evde Red Hat'ten Ubuntu'ya geçtiğimde, tipik RHEL deposunda ~ 3000 paket bulunuyordu, aynı zamanda ubuntu + universe + multiverse de hepsi herhangi bir Canonical aynadan elde edilebiliyordu, ~ 30.000 paket (yaklaşık 10x). RPM formatında aradığım paketlerin çoğu, basit arama ile kolayca erişilebilir değildi ve paket yöneticisine tıklayın. Alternatif depolara geçmeyi, rpmfind servis web sitesini vb. Aramayı istediler. Bu, çoğu durumda sorunu çözmek yerine, hangi bağımlılıkların doğru şekilde yükseltilebileceğini veya yükseltilemeyeceğini kısıtlamaksızın kurulumumu bozdu. Yukarıda Shawn J. Goff tarafından açıklandığı gibi "bağımlılık cehennemi" fenomenine çarptım.
Ubuntu / Debian'ın aksine, neredeyse hiç bir kaynaktan inşa etmem gerekmediğini öğrendim. Ayrıca, çünkü:
Resmi (Canonical) geliştiriciler tarafından bakımı yapılmasalar bile, değer verdiğim daha eski paket sürümlerinden asla ödün vermek zorunda kalmamıştım. Anahtar kelime ile uygun bir arama yapmak, istediğim herhangi bir paketi bulmak ve kurmak için favori dostu GUI paket yöneticimden ayrılmak zorunda kalmamıştım. Ayrıca birkaç kez Ubuntu'ya debian (Canonical olmayan) paketler yükledim ve bu uyumluluğun resmi olarak garanti edilmemesine rağmen gayet iyi çalıştı.
Bunun bir alev savaşı başlatmaya yönelik olmadığını unutmayın, sadece iki yıl boyunca paralel olarak kullanılmış olan deneyimimi paylaşıyorum (işten eve).
Önyargı paket biçiminden değil, RedHat'ın depolarında var olan tutarsızlıklardan kaynaklandığını düşünüyorum.
RedHat'ın bir dağıtım olduğu zamanlar (RHEL, Fedora ve Fedora Core günlerinden önce) insanlar bazen kendilerini "RPM Cehennem" ya da "bağımlılık Cehenneminde" bulacaklardı. Bu, bir deponun, birbirini dışlayan bağımlılıkları olan (genellikle birkaç katman derinliğinde) bir paketi olan bir sonuç vermesiyle gerçekleşti. Veya iki farklı paketin birbirini dışlayan iki bağımlılığı olduğunda ortaya çıkar. Bu, paket biçimiyle değil, havuzun durumuyla ilgili bir sorundu. "RPM Cehennem", sorunun yakıldığı bazı Linux kullanıcılarının nüfusu arasında RPM sistemleri için bir belirsizlik bıraktı.
Ayrıca, Debian paketlerinde soru sorabileceğiniz ve bu sayede kurulum işlemini engelleyebileceğiniz “felsefi” bir fark vardır. Bunun kötü yanı, bazı paketlerin siz yanıtlayana kadar yükseltmelerinizi engelleyeceği yönünde. Bunun iyi yanı, aynı zamanda felsefi bir fark olarak Debian tabanlı sistemlerde, bir paket kurulduğunda, her zaman istediğiniz şekilde değil yapılandırılmış ve çalışıyor. / Usr / share / doc / * bir varsayılan / şablon yapılandırma dosyası oluşturmanız / kopyalamanız gereken Redhat tabanlı sistemlerde değil.
RPM'lerden hoşlandığım bir şey delta RPM'lerin (en son?) Eklenmesidir. Bu, gerekli bant genişliğini azaltarak daha kolay güncelleme sağlar.
DEB'ler standart ar dosyalarıdır (içinde daha fazla standart arşiv bulunur), RPM'ler "özel" ikili dosyalardır. Şahsen eski uygun olduğunu düşünüyorum.
Kafamın üstünden düşünebildiğim sadece iki şey. Her ikisi de çok karşılaştırılabilir. Her ikisi de paketleme için mükemmel araçlara sahiptir. Birbiri ardına pek çok yararı olduğunu ya da tam tersi olduğunu sanmıyorum.
rpm2cpio.shsenaryoyu bulabilirler .
OpenSUSE Build Service (OBS) ve zypper, paketleyiciden ve kullanıcı bakış açısıyla deb'i RPM'ye tercih etmemin birkaç nedeni. Zypper uzun bir yol kat etti ve oldukça hızlı bir şekilde tehlikeye atıldı. OBS, borçları idare edebilmesine rağmen, openSUSE, SLE, RHEL, centos, fedora, mandriva, vb. Çeşitli platformlar için rpms'leri paketlemek konusunda gerçekten güzel.
Debian paketleri kurulu bir boyut içerebilir , ancak RPM'lerin eşdeğer bir alana sahip olduğuna inanmıyorum. Paketteki dosyalara dayanarak hesaplanabilir, ancak kurulum öncesi / sonrası komut dosyalarında yapılabilecek eylemler nedeniyle güvenilemez.
Her bir paketleme formatı için mevcut olan bazı özelliklerin karşılaştırılması için oldukça iyi bir referans: http://debian-br.sourceforge.net/txt/alien.htm (web sunucusuna göre, bu belge oldukça eski : Son Değişiklik: Sun, 15 Eki 2000, bu yüzden bu en iyi referans olmayabilir.)
Debian Paketleri için geniş bir yardımcı senaryo seti, tutarlı bir politika el kitabı ve neredeyse her şeyi yapmanın en az bir yolu var. Bağımlılıklar çok iyi ele alınmakta ve çok iyi taneciklilik içinde tanımlanabilmektedir. Paketleri yeniden oluşturmak debian paketleriyle çok kolaydır ve mevcut araçlar tarafından iyi desteklenir.
Diğer cevapların hiçbiri aşağıdaki üç temel farkın gerçek sonuçlara nasıl ulaştığı ile ilgili değildir:
debdosyalar sadece ariki sıkıştırılmış tarball içeren arşivlerdir.debpaketleri ve dpkgsistem, kaleci komut dosyalarınızı ayrı dosyalar olarak saklar.dpkgve rpmyükseltme komutları sırasında bakıcı komut dosyalarını farklı bir sırayla çalıştırın.Birlikte, bu farklılıklar o yapmış çok daha kolay bana kötü paketlerinin yol açtığı sorunları çözmek için, ve paketleri üzerine, ben onları gerek şekilde davranmaz yapmak için debolduğundan daha tabanlı sistemler rpm, tabanlı sistemlerde hem sistem yöneticisi olarak ve bir paketleyici olarak .
# 1 nedeniyle, bir debdosyayı değiştirmem gerekirse , çoğu sistemde bulunan standart araçları kullanarak önemsizce açabilir, istediğim değişiklikleri yapabilir ve yeniden paketleyebilirim .
Bu, bağımlılıkların veya paket dosyalarının veya koruyucu komut dosyalarının herhangi birinin değiştirilmesi / eklenmesini / kaldırılmasını veya paket sürümünün veya adının değiştirilmesini içerir.
# 2 nedeniyle , zaten yüklü olan bir paket tarafından yüklenen "remove" komut dosyalarında bir sorun varsa, herhangi bir sistemde bulunan standart araçları kullanarak önemsiz bir şekilde düzeltebilirim .
# 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 "post- install" betiğinden önce "install" komutunu çalıştırır . Eski versiyon
Bu, “geri kazanılabilirlik ilkesini” ihlal eden yüzey alanının debpaketlerde daha küçük olduğu anlamına gelir : paketin daha eski bir sürümünde daha fazla hata yeni bir sürümle giderilebilir.
Ve paketi değiştirmek çok kolay olduğundan - pakete özgü gerçek kemanlama ve bilgi ek yükü küçüktür - daha fazla insan için erişilebilirdir ve dosyalarla daha az zaman ve emek debharcar.
debian, dizin, yukarı akış kaynağının içine alındığı dizinde bulunur ve Debian, bozulmamış yukarı akış kaynak tarball konseptine çok değer verir. Bir kaynak paket oluşturulduğunda, birlikte kaynak paket olarak adlandırılan üç (yerel paket için iki dosya) dosyası vardır: yukarı akış tarball (tercihen bozulmamış, Debian politikası bazı projelerin yeniden paketlenmesini gerektirir), yeni 3.0 formatı (eski 1.0 format için bir fark) ve bir .dsc.