Hem rpm'yi hem de debian paketlerini destekleyebilecek bir Linux dağıtımı oluşturmanın teorik olarak mümkün olup olmadığını merak ediyorum.

Her ikisini de destekleyen orada herhangi bir dağıtım var mı?

Ve eğer mümkün değilse bile?

Bedrock Linux bunu yapar. Bunu yaptığımı ya da bunun iyi bir fikir olduğunu söylemiyorum, ama yapılıyor.

Her ikisini de doğal olarak destekleyen herhangi bir dağıtım olduğunu düşünmedim, ancak gelişimde bir tane olduğu ortaya çıkıyor , Bedrock Linux ( bilgi için iMalinowski'ye teşekkürler ). Diğer dağıtımlarda alien, bir formattan diğerine dönüştürme gibi dönüştürme araçlarını kullanabilirsiniz . Yazılım tabanlı herhangi bir şey yapılabilir, yeterli zaman ve enerji verildiğinden, bu tür bir dağıtım oluşturmak mümkün olabilir (ancak, özellikleri .debile .rpmpaketler arasındaki farklılıklar göz önüne alındığında oldukça zor).

Bununla birlikte, tüm bunlar muhtemelen her iki paket biçimini de desteklemenin hayatı kolaylaştıracağı fikrinden kaynaklanmaktadır, çünkü daha sonra istediğiniz yerden paketleri kurabilirsiniz (peki, a .debveya sağlayan herhangi bir yere .rpm). Felsefi olarak, bu kusurlu. Bir dağıtım tutarlı bir paketler kümesidir; Bu dağıtım için bir yazılım sağlamak istiyorsanız, gerçekten de paket biçimini (ve daha da önemlisi meta verileri) kullanmayı da içeren, özellikle hedeflemeniz gerekir. Yerel olarak çoklu paket formatlarını desteklemenin bir anlamı yoktur.

(Debian dünyasında, paketler ana hedefleri olmayan değişkenler üzerinde çalışabilir, çünkü paket isimlendirme oldukça homojendir ve çoğu dağıtım bir kalıtım ağacına uyar. RPM dünyasında bu doğru değildir. Her iki durumda da karıştırma ve eşleştirme kötü bir fikirdir.)

Dağıtımınızı, diğer dağıtımlardan bir şeyleri karıştırmadan, dağıtımınızın kurallarına ve ekosistemine bağlı kalarak istediğiniz sistemi oluşturmak için bir temel olarak düşünmelisiniz. Karıştırma ve eşleştirmeyi desteklemek için (veya bunun yerine çapraz dağıtım ortamları sağlamak için) daha yüksek düzeydeki soyutlamalara ihtiyacınız var: Steam çalışma zamanı, Flatpak, vb.

Hayır, böyle bir canavar yapılmamalı. Söylenenin aksine, tipik olarak uygulamanın işletim sisteminde çalışması için gereken her şeyi içeren bir MacOS uygulama paketi, RPM ve .deb paketleri neredeyse her zaman paylaşılan kütüphaneler gibi diğer paketlere bağlıdır. Linux paketleri, bulunması gereken diğer paketleri listeler ve paket yöneticisi bu gereksinimleri uygulamanıza yardımcı olur. Ayrıca, Linux dağıtımları işlerin yapılma şekli bakımından farklılık gösterir (örneğin /etc/network/interfaces.d,/etc/sysconfig/network-scripts ).

İsteğe bağlı havuzlardaki paketleri aynı paket biçimindeki aile içinde bile karıştırmamalısınız. Yani, bir CentOS makinesine SuSE paketleri kurmak, ikisi de RPM kullanıyor olsalar bile, sadece sorun istiyor. Ne yaptığımı tam olarak bilmediğim sürece, aynı işletim sisteminin farklı bir sürümü için hazırlanmış paketleri (örneğin 16.04 sistemde Ubuntu 14.04 paketleri) bile yüklemedim.

Bu yüzden, hem RPM'yi hem de .deb'ı aynı sistemde desteklemeye çalışmak söz konusu değil. Bazı çaresiz durumlarda, kullanarak belirli paketleri dönüştürebilirsiniz alien, ancak kaçınılmaz olarak bu tür saldırılardan kaynaklanabilecek sorunların giderilmesi için çok çaba sarf etmeyi beklemelisiniz.

Eh, orada alien( adam sayfa arasında dönüştürebilirsiniz), rpm, debvb ama gerçek sorunlar bağımlılıkları (yazılım için farklı paket adları) ve yapılandırma dosyalarının konumlarını ele gelen varsayılabilir.

Elbette, eğer her iki tür paketin de dağıtımın kendisinden gelebileceğini, muhtemelen etrafta çalışabileceğini, ancak o zaman neden birisinin bunu yapmasını istersen ... , çünkü dpkgveritabanlarının nasıl okunacağını bilmiyorum rpmve bunun tersi de geçerlidir.)

Evet, mümkün, ama dağıtımı mahvediyor.

Paketler yalnızca bir formattan diğerine kolayca taşınabilen format değildir.

Not: paket yükleme araçlarının taşınması gerekir, çünkü biri tüm paketlerin, sürümlerin, bağımlılıkların, yapılandırma dosyalarının, yükleme öncesi ve sonrası komut dosyalarının merkezi bir listesine sahip olmak ister (bir paketi diğeriyle değiştirirseniz, başka bir pakette) biçiminde, kaldırma komut dosyalarının (eski biçim) yeni paket sistemden çalıştırılmasını beklersiniz.

Ancak bir dağıtım ve paketler bir paket biçiminden çok daha fazlasıdır. Örneğin, Debian için: dosyaları doğru yere koymak istiyoruz, manuel sayfayı sağlamak istiyoruz, bazı ortak deamonizing komutlarına sahip olmak istiyoruz, programın birçok mimaride, çeşitli grafiksel ortamda çalışmasını istiyoruz, böylece bir kullanıcı bulur Bir dağıtım içinde yeni paketlerle de tanıdık. Paketler.

Debian'da paketlerin kullanıcılar tarafından kolayca üretilebilmesini istiyoruz (kaynaklardan), böylece bazı önemli (onun için) paketleri özelleştirebiliriz. Bu, çoğu yazarın sağlayamadığı bir çok altyapıya ihtiyaç duyar (çeşitli mimarilerde otomatik yapı ve test ve zaman zaman yapılır). Ayrıca Debian'a özgü lisans, lisans şartlarının gereğidir, böylece tüm paketleri kontrol etmeye gerek kalmadan bir paketi veya dağıtımı çatallamak daha kolaydır.

Sonunda, dağıtım yalnızca paketlerle değil, tutarlı paketlerle de yapılır.

Evet ve çoğu .deb merkezli dağıtım zaten bunu yaptı, ama ...

Debian ve ilgili ailelerde, en azından, alienRPM paketlerini kurmanıza izin verecek olan var .

Biçime bakılmaksızın yabancı paketleri yüklerken dağıtımınızla çalışmak için tasarlanmamış paketleri karıştırırken aynı sorunları yaşarsınız - DEB tabanlı bir sisteme bir RPM yüklerseniz, bu RPM'nin sisteminizle uyumlu olması gerekir. tıpkı bir RPM tabanlı sisteme bir RPM paketi takıyormuşsunuz gibi, hepsi bu. Yapabilirsin, ama muhtemelen istemezsin.

Evet ve hayır. deb ve rpm sadece biçimlerdir. Her iki formatı da destekleyebilirsiniz ancak bunun anlamı yoktur. Paketler genel olarak dağılımlar arasında karşılaştırılamaz, özellikle birbirine dayanmayan dağılımlar.

Eğer tüm dağıtımlar aynı versiyonlama gereksinimlerine sahipse, tüm dağıtım bir paket seçimi olacaktır. Herhangi bir dağıtımı paketleri listeleyerek yükleyebilirsiniz.

Ancak dağıtımlar destekleyebilecekleri bir yazılım sağlamalıdır. Uygulamanızı çalıştıran bir kitaplık sürdürülmüyorsa ve kendisi başka bir şey tarafından değiştirilmiş bir kitaplık gerektiriyorsa, bu anlaşmazlığı nasıl çözersiniz? Paket yöneticisi kodu taşıyamaz. Farklı dağıtımlar tarafından seçilen birden fazla halefi olabilir.