Paketleyici

Paketleyici Beyin Fırtınası

Aşağıdaki fikirler opensuse posta listesinden alınmıştır. Farklı kişilerden geldiklerinden, sıralanmamıştır ve birbirleriyle tutarlı değildir. Yeterli maddeye sahip olduğumuzda, daha tutarlı hale getirmeye başlayabiliriz.

Bu liste SUSE.de tarafından, kendi tartışmalarıyla bütünleştirmek için kullanılabilir. İşte size openSUSE çalışmasını nasıl "açık" hale getirebileceğimiz, nasıl geliştirebileceğimiz, ve nasıl yalnızca diğerlerinin yaptıklarını yapmayacağımız konusunda katkıda bulunmak için bir fırsat. Diğerlerinin yaptığı tüm iyi şeyleri bütünleştirin ve bundan daha fazlasını yapın. Geleceğe bakın. Yaratıcı olun. Çemberin dışından düşünün ya da yalnızca kendi deneyimlerinizi bildirin.

Genel Fikirler

• Tüm dünyadaki potansiyeli kullanacak basit bir düzeneğe ihtiyacımız var. Diğer türlü, doğrudan mükemmel çözüm için yola çıkarsak, asla ulaşamayabiliriz. Aşağıda gördüğüm hedefler ve onlara nasıl ulaşacağımız yazılı:

• • Debian(Ubuntu)/Fedora/Gentoo ve diğerlerinden olumlu ve olumsuz şeyleri öğrenmemiz gerek
  • Daha düşük posta yoğunluğu olan bir posta iletişim listesi gerek
    • Düşük yoğunlukta bir paketleyici listesi bir çelişki değil mi? ;)
    • Zorunlu olarak değil, yalnızca şu anda SUSE için çok az sayıda paketleyici olduğundan
  • Burada RPM ve DEB dışında daha farklı paketlere mi bakıyoruz? Bir *Red Hat* Paket Yönetim Dosyasından başka bir openSUSE paket yönetici dosyası (openSUSE Package Manager file - OPM) konusunda bir gereksinim/fırsat mı var?
    • Bir işletim sisteminde paket yönetimi en önemli alt sistemlerden biridir, ve önuçta iyi bilinen paket biçimleri ve paketleme araçları çok önemlidir -kanıtlanmış- - RPM söz konusu olduğunda benim fikrim tekerleğin yeniden icadına gerek olmadığıdır, RPM'e önuçlar konusunda farklı seçenekleri tartışmaya açmalıyız.
  • Central hosting, automated rebuilds when packages earlier in the dependency chain change.
    • Bunu kurmak *gerçekten* çok karmaşık, düşünülmesi gereken çok şey var, tanımlanması gereken ilkeler, uyulması gereken kurallar, kurulması gereken teknik altyapılar... Hızlı olmak gerçekten güzel, bişeyler yapmak için istekli olmak, ancak bunu doğru oalrak kurmak zaman ve uzun tartışmalar gerektiriyor. Bu yüzden, yapılabilir olmayan ya da tasarımı zaten hatalı olan şeylere atlamayın. Bunların tümünü denemiş bir kaç kişi var ( evet mütevazi bir şekilde kendimi de dahil ediyorum) ve bana inanın çoğunuzun düşündüğünden çok daha karmaşık.
    • Ne zamandan beri, çok çalışma ve karmaşa insanların yaratıcılığını engelledi? Yalnızca yeni bir şeyleri deneyerek, gerçekten çarpıcı sonuçlar yaratabilir miyiz? Kendimizi mevcut olanla sınırlayarak, başarımızı eskiyle sınırlıyoruz. Bu bir beyin fırtınası, beyin özürlülüğü değil ;)
  • Lütfen, Debian modelinden daha ileri düşünelim.
• Yapım paketleri hakkında bazı bilgiler :
  • SUSE_Build_Tutorial and **Novell Guidelines
  • GURULABS-RPM-GUIDE-v1.0.PDF

Yapı sunucuları

• Roadmap (yol haritamız) yapım sunucularından söz ediyor. Konu, farklı kaynaklardan gelen paketlerin nasıl bütünleştirileceği ve paketleme sisteminin götürdüğü gelecek topluluğunda nasıl birleştirileceğidir. Roadmap (yol haritası) openSUSE'nin paketleyicileri bir araya getirmeyi planladığını belirtiyor. Bunu nasıl yapacağız ve kullanılabilirliğini güçlendireceğiz ve hepimizin hayalini kurduğu dağıtımı nasıl yaratacağız?

• Bir genel yapım sunucusu bir çok bilinmeyeni çözecektir. Yapım sunucusunun tar ball kaynağına yalnızca URL kabul ettiğini düşünün. Bu URL, indirici kullanıcıların kaynak URL'i doğrulayabilmesi için derlenmiş RPM ile bütünleştirilmiştir. Yapım sunucusunun kaynakları almada kullanabileceği alan öneklerinin de bir listesine sahip olacağız. RPM'yi kimin yaptığı gerçekten önemli olmayacak- kaynak doğrulanmış ve yapım ortamı güvenilir olacak-

• Anasistemin taşması nasıl engellenecek? belli bir büyüklüğün üzerindeki yüklemeler için az sayıda insana yetki verilebilir. Çalışmayı yetkilendiricilerden dağıtmak için, çoklu destekler (brackets) kurabiliriz, örn. 1MB, 10MB, 100MB. Birçok küçük dosya yüzünden taşmayı önlemek için de kullanıcı başına bir kota koyabiliriz.

• SUSE.de autobuild kullanılacak mı?

• Benim fikrimce, gerçekten yararlı olabilecek ilk şeylerden biri, SUSE'nin iç yapım altyapısı anlamında daha açık olmaya başlamasıdır. Hali hazırda bence, paketleri oluştururken yapılan bazı şeyler gereksiz yere karmaşık, çünkü SUSE'nin Autobuild 'i hakkında bilgi duvarların ardında saklı. Pakete daha fazla halk tarafından katkıda yapılarak daha iyi bir yapı altyapısı oluşturulacağından oldukça eminim.

• Belki daha fazla dağıtım yaklaşımı araştırmaya değer. Ben, özellikle Debian'ın ihmal edilmiş yapısı daemon'ı beğeniyorum, geliştirmeye ihtiyacı olsa da. Ancak bunun gibi, RPM yazmak için gerekli bilgiye sahip olmayan ancak katkıda bulunmak isteyen insanlar bile kendi donanım kaynaklarını yapı sunucusu olarak ortaya koyabilirler. "tek" ihtiyaçları, RPM'i kuyruktan çeken, onu yapılandıran ve geçerli kılan; daha sonra olası sorunları bildiren ve hatta ikili (binary) paketi merkezi depoya geri getiren daemon'ı çalıştırmaktır. Açıkçası, bu kavram bir çok olası güvenlik sorunu ortaya çıkaracaktır.

• • ix86 ve amd64 dışında başka ortamlara yapı gücü bağışlayabilecek düzenlemeler bulabilir miyiz? Ancak bu başka bir kurtçuk kutusunu açacaktır: kendi yapmadığımız bir pakete nasıl güvenebiliriz? Bir uzak yapı ana sisteminde her şey olabilir, spec dosyaları ve yamaların bize bir yardımı olmayacaktır. Debian bununla nasıl başa çıkıyor?

• • SETI@home gibi diğer eşler arası hesaplama istemcilerinde güvenlik sorunu nasıl ele alınıyor? Belki bir SUSEbuild@home sistemi büyük bir derleme kümesi yaratabilir?

Depolar

• Çok sayıda RPM nasıl toplanacak, herkese ücretsiz bir hesap açmaları ve RPM'leri yüklemeleri için için izin vermeliyiz.

• Örneğin mevcut olan güncel depolara bakalım. Bunları kullanmak neden bu kadar zor? Çünkü hiç bir ortak temel, bir işbirliği olmadan ve çok az iletişimle bir çok farklı "projelere" yayılmışlar. Bu durumun çözümü oldukça zor, çünkü herkes kendi ağ alanına, spec makrolarına, bina yapısına, depo yapısına ve paket depolarını yönetmek için gerekli tüm diğer şeylere alışkındır. Beni yanlış anlamayın, pascal, james, susers-*, the packmans gibi herkes yaptıklarıyla gurur duyabilir ve ilerlememiz ve bunları başarmamız iyi bir şeydir. Ama şimdi, bunu bir sonraki seviyeye taşıma ve openSUSE şemsiyesi altında birlikte çalışma zamanıdır ki bu süreç bazı suseciler, pascal ve biz (packman) tarafından zaten başlatılmıştır.

• Bu paketleri tutmak için çok fazla yere gereksiniminiz var.

• Belki de, yum, apt ve yast depolarını evrensel bir yast sisteminde bütünleştirmeliyiz.

• Packman'i http://packman.links2linux.org'le nasıl bütünleştiririz? Packman tek yer mi olmalı? Packman dışında başka herhangi bir şeye ihtiyacımız var mı?

• • Bu mümkün olabilecek mi? Packman bir çok ülkede yasa dışı sayılan paketleri içeriyor. Eğer bu proje openSUSE şemsiyesi altında kalmak istiyorsa, bu tür paketler kesinlikle oyunun dışında kalmalıdır (kopya-koruma ve lisansız ortam kodeklerini düşünün). Belki bu tür paketler için OpenSUSE projesi dışında tek bir depo olması iyi bir fikirdir.

• Bunların bazıları (temel ve gerçekten güvenilir olanları), YaST'ta ana kurulumdan sonra kurulum kaynağı olarak seçilebilseydi bir düzen sağlanmaz mıydı? Böylece, daha fazla paket kurma ve hatta güncelleme için erişilebilir olurlardı. İnsanların üçüncü-taraf paketleri ile ilgili yaşadıkları en büyük sorun şu anda onları anlamaktır.

• "desteklenmeyen"den söz etmek; bu benim YaST'ın yapılandırmasında "güvenilir" depoları da içeren şikayet konum. Bunun için YaST'ın bazı ince düzenlemelere gereksinimi olacaktır:

• • Yeni depoları ya da bunlar içindeki değişiklikleri güncel tutmak, 3.taraf depo listelerini "yenileyebilmek" (YOU'nun şu anda yansılarda yaptığı gibi) amacıyla merkezi bir yerleşimden bir depolar listesi indirmek (örn.download.opensuse.org)
  • YaST2 depoları için bir tanım alanı oluşturmak; burada bir depodan ne beklediğimiz hakkında bilgi verebiliriz (örn. multimedya (yaşadığınız ülkeye bağlı olabilecek ihlaller hakkında uyarılar ile), deneysel gnome paketleri vs vs)
  • RPM anahtarlarını güvenli bir şekilde yönetmek; çünkü YaST şu anda paket mühürlerini denetlemiyor
  • Depolar üzerinde bir "güven seviyesi" ya da sabit/düzensiz/deneysel etiketlere sahip olmak; yalnızca kullanıcıları bir risk alıp almadıkları konusunda bilgilendirmek adına
  • Bu özelliklerle birlikte, YaST'tan üçüncü-taraf depolarını ekleyebilirlerse bir çok kullanıcı için büyük fayda sağlanacaktır. Kurulumdan sonra, YaST mevcut kaynaklarla önyapılandırılmış olacak ve ek depolar yaratmak için bir seçeneğiniz olacaktır; ancak, internette bilgi bulmak zorunda olmak yerine, merkezi bir yerleşkeden getirilmiş/yenilenmiş ve kullanıcının eklenecek depoyu seçeceği bir liste şeklinde görüntülenecektir.

• İlke olarak, tamamen açık bir yükleme politikası kabul edilebilir ve ayrı depolar için önerilebilirdir. Savın sağlığı için, bunu SUPER depo olarak adlandıralım. SUSE ve OSS yayımları

iş hayatında ve olağan kullanıcı topluluğunda bir ürün olarak değer görmeleri için kalıcı ve ticari seviyede kalmalıdır; bunlar Novell ve SUSE'nin ticari geleceği için temeldir.1 CD kurulumu bazlı topluluktaki bir ek depo, ana akımın olabileceğinden daha deneysel olabilir. SUPER = Deneysel - SUSE Linux = Sabit Dallar (Stable Branches). İsim bu olmak zorunda değil ;)

• Ciddi misin? İnsanlar sistemlerine tesadüfi yazılımlar mı yükleyecekler? Burada güven önemlidir. Kullanıcı sistemlerini kıran ilk paketler gelir, verilerini siler, arka kapılar kurarsa...openSUSE bundan zarar görür. Ben de herkesin paketlere katkıda bulunması gerektiğine inanıyorum, buna rpm ile daha yeterli uygulama yapmamış olan insanlar da dahil ( örnek olarak ben de bunları nasıl yapacağımı yeni öğreniyorum) Ama bu paketler, depolara yüklenmeden önce daha fazla uzman ve güvenilir insan tarafından gözden geçirilmelidir.

• Herkes kafasına göre bir şeyler yükleyebilirse kalite yönetimi nasıl sağlanacak? Değişken, denenmemiş, ya da nasıl isimlendirirseniz; depolar yeterli midir?

• Bunu uygulamak için en iyi yol, farklı depolara sahip olmaktır. Biri sabit, biri değişken için ve biri denem için (bunları "güvenilir", "denenmemiş" ve "güvenilmez" olarak da adlandırabilirsiniz. Böylece her kullanıcı YaST2'de görmek istediği depoları seçebilir. Bir yol da, her bir pakete inen "kalite etiketi" dir.

• Eğer 2 ya da 3 depoya ayırırsak (sabit/değişken/deneme), kullanıcı YaST2'de görmek istediği depoları seçebilir. Eğer riskli paketleri yüklemeye hevesliyse, "değişken" ve/veya "deneme" depolarını ekleyebilir. Güvenli tarafta kalmak istiyorsa, yalnızca "sabit" depoları ekler.

• Elbette, bu sistem mükemmel değil, ve bazen Debian'ın da yarattığı gibi bazı sorunlar çıkarabilir. Eğer, biri bazı GNOME kitaplıklarının en son-en güzel sürümlerini paketlemek isterse ve başka biri bu son GNOME kitaplıklarını gerektiren en son GIMP devel sürümlerini kurarsa, çok geniş bir kitaplık yükseltimi içine gireriz ve bu da sistemdeki tüm diğer GNOME uygulamalarını bombalamak demektir.

• Bir paket seti, örneğin, YaST kullanım için yapılandırabileceğiniz kendi kurulum kaynağında sonuç verir. Örneği yeniden alırsak, openSUSE topluluğu, gözden geçirilen ek setin SUSE linux çekirdeği üzerinde temel dağıtım olarak temellendirilebileceğini onayladı, ancak ek olarak şu paketleri içerecek :

• • Esas dağıtım içinde değil
  • Esas dağıtımın içindekinden daha yeni
  • Esas dağıtımdakinden daha iyi(i.e. -adding patches which didn't or will never make it into core SUSE Linux)

• Geniş bir paket havuzunu düşünün; bir dağılım değil; deneme olarak bile adlandırılmamış. Yalnızca ilkel bir paket grubu.. Herkes buraya paketlerini ekleyebiliyor. Şimdi, daha büyük bir oluşum tanımlayabileceğinizi düşünün, bunu, yaratabileceğiniz ve sorumlu olabileceğiniz bir paket seti olarak adlandıralım; burada gözden geçirdiğiniz paketleri toplayabilir ve kalite standartlarınızı belirleyebilirsiniz. Bunu, "Pascal'ın Onayladığu SUSE Ek Paketleri" olarak adlandırın, ya da bu paket seti için ayrıcalıkları olan ve size yardım edecek insanlardan oluşan bir grup kurun. Hey, hatta bunlardan üç tane yaratabilir ve "sabit", "değişken" ve "deneme" olarak adlandırabilirsiniz ;)

• Ancak bu bir çok paket seti arasından yalnızca biri olacaktır, farklı denetim ve güvenlik seviyeleri ile SUSE Linux core bir diğeri, SUPER bir diğeri; ve biz Novell insanları çok az bir kısmını denetliyor olacağız.

• Hem yapım aşamasında hem de kurucu içinde bağımlılıkları dikkate almamız gerekmektedir. İkinci ve üçüncü gruplarda, paketler asıl (core) dakileri geçersiz kılacak, bu durumda hem yapım sunucusu hem de YaST (insanların kullanmak isteyeceği herhangi bir başka kurucu) paket setlerinin ve sonuçtaki kurulum kaynaklarının "tabakalandırılması"yla (layering) başa çıkabilmeye gereksinim duyacaktır. Ki bu, hâlâ geliştirmemiz gereken bir konudur, ancak, neyse ki hem yapı sistemini hem de YaST denetimimiz altında.

• Yani, çelişkili ve eş (duplicate) paketler gerçekten bir sorun değil - örneğin deneysel ya da yalnızca daha yeni özellikler içeren değişken paketlere sahip olmak da bir özellik olabilir.

• ( Gereksinme Ekleme : Ağ ön ucunda her paket için, paket için hangi değişikliklerin var olduğu, bunların hangi paket setinin içinde olduğu, bağımlılıklarının ve amaçlarının ne olduğu, bilgisini göster. Ayrıca, bu bilgiyi YaST'ta da erişilebilir yap, ancak, gerçek yaradan daha fazla karmaşa yaratabilir. Her durumda, YaST'ın belirlenen bir tercih sırasına göre çok sayıda kurulum kaynağı ile ilgilenmesini sağla.)

• Paket seti, yalnızca sürüm temelli ve hiç bir gerçek ikili (binary) kurulumu olmayan bir spec dosyası kadar basit olmayabilir mi? Bu şekilde, bağımlılık özel bir paket seti gerektirecektir.

• Paket setleri, _bazıları_ üzerinde sıkı bir gözetim olasılığını kaybetmeden, denetimin çoğunu gevşetebileceğimiz ve daha fazla deneysel çalışmaya olanak tanıyabileceğimiz mini depolardır. Sakın, $$$ ürünleri için de kullanılacak asıl kod tabanınına gelişigüzel teslimiyetlere izin vereceğimizi düşünmeyin.

• İki depoya sahip olmaya ne dersiniz? Biri güvendiğiniz, denetlediğiniz, iyi düzenlenmiş paketler, diğeri _herkesin_ paketlerini koyabileceği, YaST'ın kullanıcıya, eğer kurulum için böyle güvensiz bir paket seçmesi durumunda BÜYÜK KIRMIZI UYARI verdiği ?

• Birincisi : Fedora dünyasından gelen ben, sistemlerinden derinden etkilendim : Bir tarafta, olağan bir sistem için gereksinim (!) duyulan ve ticari işler için temel olan ana sistem. Ve topluluk paketleyicileri için tüm diğer şeylerle fazladan depolar. Ayrıca her ikisi için de bazı geliştirme dalları var ki, bunlara bakarak bir çok şey öğrenebiliyoruz ve gerekeni edinebiliyoruz.

• İkincisi: Fedora Çekirdeği (Core) iyi yönetilen, hepsi aynı nitelikte spec'leri eilde etmek için bir olasılık olabilir. Eğer bu iki dağıtım, spec'lerin değişiminde "fazladan" dallar için uyumlu spec'lere sahip olabilirse (ve yalnızca SUSE sistemlerindeki yeni paketleri kendiliğinden kurmak) - ya da, uyumluluk mümkün değilse, çalışmayı daha önemli şeylerde kullanmak için onları kolayca içeri alabiliyor olmalıyız ;) --

--Liquidat 17:58, 27 Oct 2005 (MDT)

Paketleyiciler Dünyası

• Herkes katılabilir. Herkes uygulayabilir. Ancak bu şunları gerektirir :
  • Paketin kendini adamış koruyucusu olmak
  • Gözlenmeyi kabul etmek, en azından başlangıçta
  • Nasıl paket yazılacağı konusunda bazı yönergeleri izlemek
  • Belki, diğer paketleyicilerle bir merkezi posta listesinde yer almak

• Hâlen, her 6 ayda bir sabir bir SUSE dağıtımına sahibiz, bu nedenle bu sorunlarla uğraşmayacağız. Bu sabit/değişken/deneme her bir "3. şahıs" paketine uygulanabilir.
  • deneme = gözden geçirilmemiş, denenmemiş
  • değişken = gözden geçirilmiş, yeterince denenmemiş
  • sabit = gözden geçirilmiş, en az x kişi tarafından denenmiş

• Bir pakeleyici sistemi ağ tabanlı olmalı, paketleyicinin yeni kaynak korumasını kolaylaştırmalı ( kaynak yerleşiminde bilgiyi içermeli). Bu güvenilir, özgün kaynaklardan kaynak kurulmasını sağlar.

• Paketlerin niteliği : bir dağıtım için iyi RPM'ler yapmanın anlamı, (örneğin, iyi spec dosyaları yazma) ; onlarla fazla deneyime sahip olmaktır (hem RPM yapma_hem_ dağıtımı iyi bilme)

• Sorun, nitelikli paketleri saptamaktır. Bir çözüm niteliği nicelik üzerinden saptamaktır. Bir diğeri, hepimizin karar vermesi ve niteelik bulgularımızı paylaşmamızdır. Ben, "nicelik üzerinden nitelik" yaklaşımını doğru bulmuyorum. Benim "açık" anlayışıma uymuyor, bu bizim olmak istediğimiz şey. OpenSUSE bazıları karar verir bazıları vermez SUSE değildir..

• Paketler, paketleyicilerin uzmanlığı ve güvenilirlik seviyeleri göz önüne alınmadan izin verilmelidir.

• Signoff (Oturumu kapatmak), güvenlik seviyesi ile, paketlerin denetlenmesini sağlayabilir.

Signoff can provide with level's of trust in case packages need to be tested.

• IMHO, hızla ulaşmamız gereken ilk hedef, paketlerin sınıflandırılması ve tüm benzerleri içinde hangi paketin olması gerektiğini bilmek için oylama sistemi kurmaktır. Örneğin, hangi CD yazıcı paketine ihtiyacımız var? Hangi düzenleyiciye? Tabi ki hepsinin sonunda bir "ler" olabilir (Birden fazla seçebiliriz)

• Güvenilir nedir? Güvenilmez kod için ilk çıkış noktası spec dosyalarıdır. RPM tetikleyici betikleri ile tüm kirli işlerinizi yapabilirsiniz, çünkü bunları genelde kök olarak kurarsınız. Bu nedenle, Paketleyici için de bir güvenme sistemine gereksinimimiz var. Güncel depolarla bu, paketleyiciden gpg anahtarıdır. Ancak, gpg'nin yalnızca bir paket isteyen "olağan" kullanıcı için anlaşılması ve kullanılması zordur.

• Yenilik çatallarına izin verdiğimiz bir yöntem nasıl yapılandırılır, bozdukları şeyleri nasıl tamir edeceklerini bilmeyenler için kullanılabilir/sabit ürünler nasıl yaratılır? Halka açılmak, beğensek de beğenmesek de genelde ürün çatalında bir sonuç vermez. Bazı kullanıcılar bunu, saldırgan, iddialı ve dogmatik bir şekilde "bir araya gelelim" şeklindeki hippy mantığında düşünecek ve ürünü başka bir ışık altında sunmaya çalışacaktır. (kendi standartları ve tasarımları "vorsprung durch technik !!!").

• Belki de bunu; sözcük çok sert olduğundan; "çatal" olarak adlandırmamalıyız. Nasıl açık tutarız ve paketleyiciler için düşük giriş noktası ile nasıl hızlı büyütülür, aynı zamanda da QA - paketlerin kullanılabilir olması için çıktı- denetleme yolları bulunur.

• Herhangi bir sapkın paketi kabul edecek, çok esnek bir paketleyici sistemine izin vererek, çatalların asla oluşmamasını sağlayabiliriz.

• Gerçekten demokratik ve açık, seçkin olmayan dağıtım-katılım yapısını nasıl oluştururuz, tüm insanlar aslında bir şekilde bütünleşmiş olduğundan, böyle bir yapı bir çatal gerektirecek her durumu yok edecektir.

• Hata-izleme sistemi (Bug-tracking). Katkı yapılan paketler için bir hata-izleme sisteminin kurulması bence önemli. Büyük olasılıkla bunun yararlarını tartışmamız gereksiz..
  • Zaten bugzilla'mız yok mu?
  • Evet, ama Novell bunu tüm katılımcı paketleri için kullanmak istiyor mu? Göreceğiz. Örneğin, Urbuntu'nun bugzilla'sı yalnızca onların desteklediği ana paketler için geçerli. Diğer paketler (kendi evrensel (universe ve multiverse) depoları) ayrı hata-izleme sistemlerine sahip, ana bugzillalarında onlara izin vermiyorlar.

• Birisi, aynı zamanda, paketler sunucular kurulmadan paketlerin yasal anlamda da özgür olup olmadığını (en azından hukukçu olmayan birinin yapabileceği kadar) ve güvenlik konularını araştırmalı. Bilinen güvenlik sorunları olan paketler bir yama oluşturulana kadar alınmamalı (ya da belki de, büyük kırmızı bir uyarıyla ayrı bir depoya konmalı)

• Bir "yeni paket öneri komisyonu" kurabiliriz. Bu grubun hedefi ,başka bir yerde erişilebilir olan yeni uygulamalar hakkında araştırmalar yapmak olacaktır. Onlara ev sahipliği yapmak ya da hata ayıklamak değil, yalnızca daha önce yapılmış işe ve içerebileceklerine bakmak (bağımlılıkların listesi...) Bir paket gelecek vaadediyorsa, komisyonun bir üyesi SUSE 10.0 rpm yapmak amacıyla paket geliştirme takımına katılabilir. Genelde,bu, Suse rpm'i dağıtım içerikli ürün yapmayan bir gönüllüdür. (hatırladığım kadarıyla lyx ve audacity için durum buydu).

• red-carpet ile, sabit kanala üye olabilir, ama hala değişken'den bir şeyler kurabilirsiniz; bağımlılıklar önce üye olunan kanaldan daha sonra üye olunmayandan sağlanacaktır.

• Sanal klasörler gibi dosya sistemi şeması, bu yalnızca bir fikirdir ve daha bilgili insanlar bunu herhâlde göz ardı edecektir, ama :

• • Standart dosya sistem şemasının amacı ilgili ögeleri derlemek ve onları yalnızca bir dosya ağacının bir parçası olarak yedeklemek gibi ilginç şeyler yapmaktır. Yine de, neden biz - kullanıcılar ve paketleyiciler - bu dosyalamayı yaparız? Bunu bilgisayarın bizim için yapması gerekmez mi? Bugün sanal klasörler gözde posta sunucularının çoğunda yer almaktadır. Bir sanal klasör, bir kullanıcının dizin ya da klasör olarak gördüğü, sıradan ifade için saklanmış bir aramadır. Neden aynı ilkeyi, /bin, /sbin, /usr/local/bin ve benzerlerindeki işletilebilir ikililer (executable binary) gibi erişilebilir standartları kullanarak dosya sisteminin kendisinde uygulamayalım? Bugün bir kullanıcı Kontackt istediğinde, değişik sabit dosyalardaki bir çok dosyaya erişmesi gerekir, ki, en sonunda hepsi bellekteki bir inode'a danışır ve eğer dosya adı olarak yanlış bir yok aranıyorsa bu çalışmayacaktır. Dosya bir yerlerde kurulu olsa da çalıştığınız kaç uygulama başarısız oldu? Bir uygulama bir dosya gerektirdiğinde, dosya sistemi yolları dikkate almaz - yalnızca dizibde dosyayı bulur. Eğer aramayı saklarsak, ls -l /bin hala olağan şekilde çalışabilir. Aynı şeyi, bağlantılarla da yapabiliriz, neden kaydedilmiş bir aramayla da olmasın? İlginç bir yaklaşım, dosyaların doğru arama klasörüne konması için Bayes süzgecinin kullanılmasıdır. Kontact'ı başlatmak, işletilebilir olan gibi bir çok ek dosyanın açılmasını ifade edecektir. Bayes süzgeci, örneğin, /usr/local/bin deki başlatılmış işletilebilirleri, daha sonra, /usr/local/lib da gereken ek dosyaları sıralayabilir. Sanal klasörler ya da kaydedilmiş aramalar erişilebilirdir, bırakın bilgisayar ilk kurulumdan sonra sıralama ve bulmayı
• Conary GNU Arch, marrying gibi dalları ve değişim setlerini kullanır.

Paketleme sistemine için bir denetleme sisteminin revizyonu. Oldukça ilginç bir yaklaşım!

Kullanıcıların Dünyası

• Paketleri indiren kullanıcılar kötü RPM'lerden nasıl korunacak? Her bir RPM için bir indirme sayımı ve kullanıcı yorumları tutmalıyız. Bu şekilde, indirim kullanıcıları ilk kez bir RPM kurarken hangi riskleri aldıklarını, hangilerinin kötü yorumlu olmadıklarını bilecekler. Evet, aynı zamanda biz de, indirenlerin iyi yorum yaparken iyi niyetli olduklarına güveneceğiz..

• Bir kullanıcı bakış açısından, bizim 2 depoya gereksinimimiz var; önerilen ve önerilmeyen.
  • İlkinde, belli bir dağıtım için standart olan her şey konacak. Bu güvenilir seçim.
  • Denenmemişte, geri kalan her şeyi koyacaksınız, denenmiş denenmemiş ama standarttan farklı sürümler. Örnek: Önerilen ile, dağıtımınız ile gelen KDE'yi çalıştıracaksınız. Önerilendeki tüm uygulamalar bu KDE sürümü ile çalışacak.
  • Önerilmeyende, KDE'nin daha yeni bir sürümüne sahip olacaksınız ve buradaki uygulamalar dağıtımınız ile gelen standart KDE ile çalışmıyor olabilecek. Burası aynı zamanda, yeterince denenmemiş yazılımları da içerecek. Bu biraz : kendi riskinizle çalışmak. Bir programcının bakış açısından, 3 farklı depo görüyorum, kullanıcı açısından, iki yeterli hatta bir amaç olacaktır.

• Bunun etrafında hizmetlere gereksinim olacak, RPM'lerin yalnızca http ve ftp indirimlerini sunmak değil: Bağımlılıkları yönetmek,YaST2, apt, yum ya da red-carpet kullanamadığınızda can sıkıcı bir iştir. Bu depo metadatasıyla uğraşmak öyle kolay bir iş değildir.

• "Geri bildirim" sistemi ile bir ağ tabanlı paket sistemi (yazılım ambarı), denenmiş ve doğrulanmış olan ve olmayan paket setlerini sunabilir. Bu şekilde, herhangi bir pakete izin verilebilir ve geri bildirim paketin "durumu"nu belirler (deneysel, kararlı, denenmemiş, deneniyor). Bu durum, kullanıcı hangi duruma izin vermeye karar verdiyse oradan girdi alacak dönüştürülmüş bir Yast'ta çalışılabilir. Bu aynı zamanda http://klik.atekon.de/ gösterdiği gibi ya da Linspire (Clik'n'run) gibi diğer dağıtımlardaki gibi tamamen ağ tabanlı da olabilir. Geliştiriciler için yalnızca bir Clik'n'package eklememiz gerekir. Bu konudaki beyin fırtınası SUPER KLIK.

• Bunu şöyle görüyorum, asıl OS (çekirdek, kabuk, hizmetler, sürücüler vb. + temel masaüstü sistemi) hala RMP yönetimlidir ve eğer istenirse ya da gerek duyulursa, YaST Online Update ile güncellenebilir. Ancak, eklenmiş uygulamalar, kullanıcıya daha yakın, mümkünse daha az dağıtım

ve özel paketleme için dağıtım sürümü kullanır.

• • Bu niçin, kararlı, kararsız, deneme gibi paket sınıflarına bağlanmak zorunda? Niçin bunu her bir paket için yapamıyorsunuz?
  • Daha fazla ölçütünüz olabilir :
    • İlk kez düzenlenen
    • download.opensuse.org 'tan N kez indirilen
    • SUSE Linux üzerine N kez kurulmuş (biraz "opt in" izleme uygulaması gerektirecek)
  • Buna göre, güzel olacak olan, bazı ağ arayüzleri ile kullanıcıların paketler aracılığıyla kendi deneyimlerini sunmaları için bir olanak tanımak olurdu. Bir "kararsız" paket kullanıcılardan belli sayıda olumlu bildirim aldığında "kararlı"ya terfi eder. ve "denenmekte" olan paketler, en azından 1 ya da 2 deneyimli paketleyici tarafından gözden geçirme "kararsız"a terfi eder. IMHO, bir çok potensiyel sorun için bu çok iyi bir çözüm, ancak, büyük olasılıkla bunun için bazı yazılımların yazılmasını getirecek (geri bildirim bırakmak için ağ önucu)
    • Bu paketle ilgili tüm bildirilen hataların listesi
    • Teslim olunan hataların sayısı
    • Çözülen hataların sayısı
    • Bekleyen hataların sayısı
    • Bu paket hakkında diğer kullanıcılar ne düşünüyor
    • Paket 10 (yüksek nitelik) .. 0 (düşük nitelik)
    • Paket hakkında yorumlar
  • Aslında, sonuçta bir paket kurarken bu şekilde rakamlara göre karar vermemelisinz, hangi paketleyiciye güvenebileceğinizi, hatta hangi paketleyiciye güvenebileceğinizi söyleyen hangi kişiye güvenebileceğinizi bulmanız gerek. Sonuçta, akıllı gibi görünen birisinin gerçekten akıllı mı olduğu, ya da yalnızca kendi pazarlamasını mükemmel şekilde mi yaptığı hakkında doğru yanıt verebilecek teknik bir çözüm hiç olmayacak. Ancak, gerçek şu ki SourceForge açık katılımın gerçekten işe yaradığını gösteriyor. Sahip oldukları kötü şeyler de var ancak kimsenin umrunda değil, çünkü herkes buradan istediğini indirmekte ve geri kalanını bırakmakta özgür. Hiç kimse, bu kavramın openSUSE için nasıl çalıştığını tam olarak söyleyemez ama bunu denemenin oldukça iyi bir fikir olduğunu düşünüyorum. Sonuçta bu, SUSE kullanıcılarının ne kadar zeki olduğuna bağlı. Göreceğiz..

• Hızlı gelişim ve kolay yükleme tutumu hem Novell'in ticari gereksinimini hem de topluluğun daha fazla pakete sahip olma ihtiyacını - "deneysel" olsalar da - karşılayacak ve benzer bir model - 1 CD - deneysel -kullanıcı dostu- sahip olan Ubuntu ya da büyük Debian tabanlı depo gibi diğer dağıtımlar için de bir yanıt getirecektir. Bu, paketleyiciler için düşük giriş bariyerleri ile çok heyecan verici bir dağıtım olacak ve diğer dağıtımlardan, daha geleneksel Top-Down modeli izlemek yerine, fikirlerini dağıtıma sunabilecek tüm kullanıcıları çekecektir. Seçkin olmayan ve halka açık olan; hem deneysel yaklaşım için Linuz topluluğunun hem de kararlı bir çözüm ile ticari gerçekliğin gereksinimlerini karşılayacak..

• The Zero Install System

Bazen, çemberin dışından düşünmek mevcut sorunlara yeni çözümler bulmayı getirir. Lütfen belgelendirmeyi okuyun, the security model hakkında ne yazıldığını düşünün ve sağlanan SuSE 9.3 rpm', deneyin. Otoritenin savı (not, eğer otorite olarak değerlendirmezseniz geçersizdir) : Tim Berners-Lee likes it, ancak, indirme saklı olduğundan, sürekli bağlantı ihtiyacı konusunda yanılıyor.

• • Herkes yazılım kurabilir
    • Yalnızca bir kelime-işlemci kurmak için root olmanız gerekmez
  • Herkes yazılım dağıtabilir
    • Zero Install'ın bir parçası olmak için bir kişi ya da bir dağıtım tarafından tanınıyor olmanız gerekmez.
  • Yazılımın kurulu olup olmaması sorun değildir
    • Yalnızca çalıştırın. Zero Install gerisini halleder.
  • İndirimler paylaşılır
    • Eğer bir kullanıcı 20 MB bir uygulama kurarsa, diğer biri bunu yeniden indirmeden kurabilir.
  • Kullanıcılar birbirine güvenmek zorunda değildir.
    • Eğer bir kullanıcı kötü niyetli bir program indirirse, diğer kullanıcılar etkilenmez.

• Bir çok insan, herhangi bir gözden geçirme sürecinden geçmemiş, rastgele kişilerden paket alınması durumunu çok istemez. Nitelik önemlidir. Bu nedenle, paketler teslim edilmeden önce onları inceleyecek bilgi ve isteğe sahip insanları görmek istiyorum. Bu asgari niteliği tutturmak, SUSE'nin paketleme tutumlarına uyulmasını sağlamak vb için iyi bir yoldur. Burada, niteliğin rpm'lerin sayısından daha önemli olduğunu düşünüyorum.

Paketler

• Tüm paketler mi yoksa seçilmiş bir kaç paket mi?

• Bu kesinlikle birlikte karar vermemiz gereken bir konu! Yüksek niteliği sağlamaya devam edebileceğimiz başka bir yok var mı?

• IMHO, Son kullanıcılar için buradaki sisteminizi katledebilecek RPM'li her bir projeden daha az iyi paketlere sahip olmak son kullanıcı için daha iyi bir durumdur.

• Opensuse.org sitesinde, dünyada konuya meraklı insanların SUSE için ürün RPM'lerini yükleyebilecekleri bir bölüm yaratmamız gerek.

• Paketler bir dağıtımın yapı taşları olduğundan, paketleyicilerin paketlerle uğraşma şekli esas olarak kullanıcıların paketleri nasıl, ne sıklıkla, hangi biçimde/nitelikte alacaklarını belirleyecektir. Kullanıcı bakış açısı bir geliştiriciden kullanılabilir bir paket sistemi edinmek için çok önemlidir. Uygun olarak, paketlere "kullanıcı" bakışı ve "geliştirici" bakışı tutarlı ve uyumlu ve aynı şeye iki farklı açıdan bakış olmalıdır.

• Benim istediğim RPM'ler için pro-aktive bir bakış. Örneğin, freshmeat.net'ten rss'e bakın. Yeni bir dosya gelirse, paketlemeye daha önce ekli olup olmadığına bakın ve değilse ekleyin. Daha önceden ekliyse güncelleyin. Başlangıçta, bir çok şeyin insanlar tarafından yapılması gerekiyor. Bir süre sonra işlerin otomatik olarak yapılabileceği görülecek.

• rss besini freshmeat sayfasını işaret ediyor ve daha önceden bir lisanslama bilgisi içeriyor. Freshmeat sayfası başka şeyler hakkında bilgi ve kullanılabilecek RPM/TGZ/CVS dosyalarına bağlantı veriyor.

• Ana fikir, Pakete eklenecek şeyler için pro-aktif bir görünüme sahip olma gerekliliğidir. Anladığım kadarıyla başlangıçta bu çok fazla insan müdahalesi gerektirecek, ama bir süre sonra çoğu bölüm otomatikleştirilebilecek. Eğer bir tgz dosyası mevcutsa indirme ve derleme büyük ölçüde otomatikleştirilebilir.

• Güzel olabilecek bir başka şey de,diğer dağıtımların yamalar için hata-izleme sistemlerini otomatik olarak denetleyebilmek olurdu. Amaç, bu yamaları ve hata düzelticileri OpenSUSE paket sahipleri için kolayca erişilebilir kılmaktır. Elbette, bunlar otomatik olarak uygulanamaz ancak, güzel bir listede derlenmiş olarak sahip olmak çok iyi olurdu. Ubuntu uzun vadede böyle bir sistem için çalışmıyor muydu?

• Faydası, geliştiricilerin nasıl dâhil olacakları konusunda endişelenmek zorunda kalmamaları ve bizim de daha önce freshmeat'te yer alan bazı şeyleri kaçıracağımız konusunda endişelenmememiz. Bunu yarı-otomatik olarak çalıştığını görebiliyorum.

• Deneyimlerime göre, freshmeat'te olmayan bir çok paket ve paketleyici "lzy" (tembel) ve freshmeat'i sıkça güncellemiyorlar.

• GPL yazılımı için rss'e bakın

	| Is it GPL (or other usable)    -> No -> check next / Also on the page check OS, programming language and the like
	|
   What links are there:
	|________________ RPM -> Use that
	|
	|________________ rpm.src -> Use that
	|
	|________________ tgz, bz2 and the like -> use that
	|
	|________________ unknown -> ask a human for the correct URL

Sonunucusu, gerekli bilginin bir insan tarafından eklenebileceği bir HTML sayfasına bir bağlantı ile yapılabilir. Bu insan, herhangi biri ya da yönetici grubu olabilir.

• Bazı programların güncelleme ihtiyacı yoktur, diğerleri terkedilmiş olabilir ve yine diğerleri teslim olmuş, güçlendirilmiş ve güçlendirmeler hiç teslim olmamış olabilir.

• Bunun insan etkileşimi ile yapılması gerekir. Bir yerlerde bir duyuru olacaktır, bunu gören insanlar hangi durumda olduğuna karar vereceklerdir. Hâlâ çalışıyor, terk edildi ya da yanlış sürüm. Her bir duruma göre adım atılmalıdır. Terkedilmiş ise, belki silinmelidir (ya da en azından bu şekilde işaretlenmelidir), güncellenmemişse, doğru sürüme olan bağlantı güncellenmelidir.

• Eğer bir paket, paketi korumakla yükümlü kişi tarafından etkin olarak korunmuyorsa, başkasına verilmelidir (ya da web sitesinde "korunmuyor" ve " katılmak ve bu paketi korumak ister misiniz? Buraya tıklayın" etiketi ile etiketlenmelidir).

• SUSE politikasına uymayan rpm'ler seçenek değildir. SUSE her zaman yüksek niteliğin arkasında olmuştur. Novell'in bunu değiştirmesini beklemiyorum. Bu nedenle, herhangi bir paket eklenmeden önce (tabi daha sonra da) bir nitelik sürecinden geçmelidir. Sadece rastgele şeyler alıp eklemeyin. SPEC'lerin eklenmeden önce gözden geçirilmesi, paketlerin denetlenmesi gerekir; yeni SUSE Linux sürümleri için ek paket güncellemelerinde bile birisinin paketi koruması ve bir sorunla karşılaşılırsa güncellemenin sağlanması gerekir. Aksi halde, Ubuntu'nun evreni gibi, çok sayıda paket ancak yetersiz koruyucu, bir sürü bozuk paket, güvenlik desteği eksiği vb gibi bir evrenle sonuçlanabilir. Bunu istemeyiz, değil mi?

• Ancak, gözden geçirme yeterli değildir, korunmayan paketler aynı zamanda bir sıkıntıdır. RMP'lere katkıda bulunanlar şunu anlamalıdır ;
  • Ortak bir tarzı sürdürmelidirler
  • Söz konusu paket için koruyucu olurlar ve bunu güncel tutmak ve hata gidericileri uygulamakla yükümlüdürler.

• Az sayıda insan tarafından uğraşılan çok sayıda paket olmasından kaçınmalıyız.

• Bu sorun, örneğin Ubuntu'nun evreni için görülebilir. 20 koruyucuları ve yaklaşık 8000 paketleri mevcut. Ubuntu'nun yayımı için evreni düzgün bir hâle getiremeyecekleri ortada. Bu çok büyük bir darboğaz.

• Eğer paket; denenmedi, bilinmeyen biri tarafından bırakıldı, derecelendirilmedi, güvenilmeyen yeni kullanıcı olarak açıkça işaretlenirse ve otomatik güncellemeye değil de ancak el ile açık bir müdahaleye izin verilirse ? Hâlâ karşı olur muydunuz?

• Güven önemli bir konu. Ancak, her şeyi dışarda bırakarak yalnızca güvenilir paketlere izin vermek yalnızca bir olası çözüm; ve bu diğer açık projelerde de görebileceğiniz darboğazlar yaratıyor.

• Diğer bir fikir, şeffaflık : paketin hangi güvenilirlik seviyesinde olduğunu, ne çeşit gözden geçirmelerin yapıldığını netleştirmek; kullanıcılar bir şey indirdiğinde ya da kurduğunda sakıncalarını, tehlikelerini bilmelerini sağlamak. Ancak, herkesin yapım altyapısını ve paket dağıtım sunucularını kurmalarına ve paketlerini orada tutmalarına izin vermek.

• Yazılımın sürümü . Bir örnekle açıklayayım. Paket gqview. İki sürümü var: bir kararlı (2.0.x) ve bir beta sürümü (2.1.x). Diyelim ki, SUSE 10.1, gqview 2.0.x taşıyor; çünkü şimdiye kadar SUSE politikası hep riskli olandansa kararlı sürümü seçmek olmuştur; ki en azından dışarıdan gördüğüm kadarıyla bu çok anlaşılır ve kesinlikle en iyi seçenektir. Şimdi, bir dağıtım sürümünün yaşam eğrisi boyunca (diyelim 10.1), SUSE "yalnızca" güvenliği olan hatta bazen sert hata düzelticileri olan paketler için güncelleme sağlamaktadır. Ben gqview'in en son 2.0.x ve 2.1.x sürümlerini tercih ediyorum. Güvenli tarafta kalmak isteyen kullanıcılar 2.0.x olanı, en son riskli sürümü bir denemek isteyen diğerleri ise 2.1.x sürümünü seçeceklerdir. Ne yazık ki, apt, yum ve YaST2 bu tarz şeyleri desteklemez. Eğer biri benim depoma diyelim YaST2 ekler ve kaynakları tazelerse, burada bir gqview 2.1.4 olduğunu görecek ama gqview 2.0.18

görmeyecektir.

• Bu tam bir "paket seti" için bir nitelik etiketidir. Bu yaklaşımla görülen sorunlar : Paket setlerinin içinde ne olduğunu kim denetliyor? Teknik Kurul gibi küçük bir topluluk mu? Novell Mühendislik bunu yapıyor mu? "paket setleri"ne nasıl karar veriyorsunuz? Teknik kurul bireysel paketlere bakıyor mu? Yoksa yalnızca bazı koruyuculara mı güveniyorsunuz? Bunun sizi nereye götürdüğünü görüyor musunuz? Bu, tüm insanlardaki gücü alıp bir kaç kişinin ellerine teslim etmektir.

• Paket denetimleri. Deneyimli bir paketleyicinin gözden geçirmesinin bir parçası bile değildir. Betikler şunlara güvence verir :
  • KDE paketlerinin /opt/kde3 içine kurulumu
  • GNOME ve GTK2 paketlerinin /opt/gnome içine kurulumu
  • Yapılandırma dosyalarının %config olarak işaretlenmesi
  • daemon (hayalet program)içeren paketlerin init betikleri içermesi
  • Belgelendirme dosyalarının  %doc olarak işaretlenmesi
  • Bir .masaüstü dosyasının uygun olduğunda içerilmesi/eklenmesi

• Bunun bir kısmı olasıdır, ancak ne yazık ki tamamı değil. Olası olan :
  • Tüm "desteklenen" mimarilerde gereği gibi yapımı (özellikle x86_64)
  • Bağımlılıklar dahildir ve doğrudur (**)
  •  %suse_update_libdir ve %suse_update_config, autoconf kullanırken dahildir
  •  %suse_update_desktop_file, bir .masaüstü dosyası içerdiğinde çağrılır
  • Kaynaklar için tam nitelikli yollar içerir (çok az istisna ile) (*)
  • Doğru olarak alt-paketlere ayrılır, en azından include/*, lib*.a, lib*.so gibi dosyalar olduğunda ((çok az istisna ile) (*)
  • /usr/local altına hiç bir dosya kurulmaz
  • init betikleri /usr/sbin or /sbin 'de bir "rc"-symlink içerir

• Tüm depoları kullanmak istediğinizde gerçek bir sorunsal olan bazı tutarsızlıklar yaşıyoruz, belirgin olarak:
  • paket isimlerinde çelişki
  • Birden ortaya çıkan, alt-paketlenmiş ve sağladığımızdan farklı olarak isimlendirilmiş SUSE paketlerinde çelişki,
  • Kopyalar: Birden fazla depoda yer alan paketler

• Elbette her paketin bir koruyucusu var - onu sisteme ilk kez yerleştiren kişi. Korunmayan paketlere her bakımdan dikkat edilmelidir - koruyucuları kaybolan ya da herhangi bir nedenle ilgisini kaybeden.

• Şimdi dağıtımda nasıl özel bir paketi elde ederiz? ("openSUSE'de yeni paketler yaratma tarzından)
  • Henüz "openSUSE bina altyapısı" gibi bir şeyimiz henüz olmadığından bir "resmi yönerge" mevcut değil. Şimdilik, gidilecek tek yol, bugzillada bir güçlendirme talebini dosyalama ve specdosyalarınızı buna bağlamak. Eğer paketi beğenir ve SUSE Linux'a almak istersek, çalışmanızı alır, gözden geçirir ve içeriye koyarız. Not: Bu şu anki güncel durumdur- ancak gelecekte değişecek.
• Bir çok pakete sahip olmak ( gereksiz paketlere izin vermeden) iyi olur,bazıları olması gerektiği gibi korunmasalar bile.. Ben gereği gibi korunan yazılımlardan 3 ISO, orta derece korunanlardan +4 ISO, az korunanlardan +4 ISO ya sahip olmayı, yalnızca çok iyi korunan 3 ISO'ya sahip olmaya tercih ederim. Bence, göreceli olarak kullanılmayan paketleri dağıtıma koymak faydalı olur, en azından onları hiç dahil etmemekten daha iyi.. "Çok iyi korunan yazılımlardan 3 ISO"nun niteliğinin dağıtıma diğerlerini de dahil etmekle azalması için bir neden göremiyorum. Bu durumda, bir paket zayıf korunuyorsa, herkesin katkıda bulunması ve onun niteliğinin artırılmasına yardımcı olması gerekir.

• ISO'larımızda RPM'lerimizin nasıl yerleşeceğine karar vermek için Debian'ın gözdelik yarışması gibi araçlar kullanabiliriz. (en az önemli ISO'ları "ek" ya da "isteğe bağlı" olarak işaretlemek gibi).