Pardus:Depo Politikası

PardusWiki sitesinden

Git ve: kullan, ara

Konu başlıkları

Belge hakkında

Bu belge Pardus paket depolarını ve bu depolar üzerinde uyulması gereken kuralları listeler.

Belge yalnızca bir kullanım alanına yönelik hazırlanan Pardus işletim sistemi dağıtımı için kuralları tarif eder. Farklı kullanım alanlarına yönelik, farklı Pardus dağıtımları (Pardus, Pardus Sunucu, vb.) bulunabilir. Belgede anlatılan kurallar her Pardus dağıtımı için ayrı ayrı uygulanır.

Paket depoları

Pardus dağıtımının bütünü hazırlanan yazılım paketlerinin bir araya getirilmesi ile oluşturulur. Dağıtıma eklenecek her yazılımın öncelikle Pardus paketi olarak hazırlanması gerekir.

Paketlerin hazırlanması ve kullanıma sunulmaları sürecinde iki farklı yapıda paket deposu kullanılır:

  • Kaynak paket deposu
  • İkili paket depoları

Kaynak deposu

Kaynak paket deposu PiSi kaynak dizinlerinin bulunduğu depodur. Paketler üzerinde yapılan tüm geliştirme kaynak paket deposu üzerinden yürütülür. PiSi paketleri bu kaynaklar kullanılarak oluşturulur ve ikili depolara yerleştirilir.

Pardus içerisinde o sıradaki dağıtım sürümü tarafından kullanılan kaynak depoda aşağıdaki gibi iki ana dal ve bir etiket dalı bulunur:

  • Kararlı (stable) dallar
  • Kararlı dal etiketleri
  • Geliştirme (development) alanı


Kararlı dallar
Genel kullanım için yayınlanmış olan dağıtım sürümlerinin kaynak paketlerini barındıran dallardır.

Her ilk (major) sürüm numarası için bir kararlı kaynak dal oluşturulur. Örneğin: Pardus 1.0, 1.1 ve 1.2 sürümleri aynı kararlı kaynak dalı üzerinden ikili paketler oluşturularak hazırlanır.

Kararlı sürümün yayınlanması ile de kaynak depo sürüm numarası ile etiketlenerek (taglanarak) ayrılır. Etiketlenen bu depo üzerinde geliştirme yapılmaz, buradan ikili oluşturulmaz.


Geliştirme alanı
Ana geliştirmenin yapıldığı, yeni özelliklerin ve paketlerin ilk olarak eklendiği alandır.

Yeni bir paketin ilk adresi geliştirme alanı olacaktır ve Pardus tarafından dağıtıldığı sürece geliştirme alanında barınmaya devam edecektir. Paket üzerinde yapılan geliştirme ilk bu alana uygulanır, daha sonra kararlı dallara aktarılabilir.

Yeni dağıtım sürümleri yayınlandıkça kararlı olarak işaretlenmiş birden fazla dal olabilmesine karşın, bir kullanım alanına/kullanıcı kitlesine hazırlanan Pardus sürümü için yalnızca bir tane geliştirme alanı bulunur.

Kaynak paketler için genel işleyiş

Kaynak paket deposu subversion sürüm kontrol sistemi üzerinde barındırılır. Kararlı sürüm oluşturulacağı zaman geliştirme alanı kararlı bir kaynak sistem oluşturmak için dallandırılır (branch) ve hazırlanan yeni dal üzerinde kararlı dağıtım sürümü için paketler hazırlanır.

Kaynak paket deposunun sıradüzeni aşağıdaki gibidir.

  • /devel
  • /stable
o /stable/pardus-1
o /stable/pardus-2007
o ...
  • /tags
o /tags/pardus-1.0
o /tags/pardus-1.1
o ...
o /tags/pardus-2007
o /tags/pardus-2007.1
o ...


Ana geliştirmenin yapıldığı devel alanı kararlı sürümler için dallandırılır. Kararlı sürüm geliştirmeleri bu dallar üzerinde yapılır. Gerekiyorsa geliştirme alanında yapılan iyileştirmeler, depo ve bileşen sorumlularının kontrolünde kararlı dallara aktarılabilir.

Kararlı sürüm alanlarından oluşturulacak sürümün yayınlanması ile kararlı sürüm etiketlenir ve üzerinde bundan sonra değişiklik yapılmayacak bir etiket oluşturulur.

İkili paket depoları

İkili paket depoları PiSi paketlerinin derlenmiş ve kuruluma hazır hallerinin bulunduğu depolardır. Pardus içerisinde o sıradaki dağıtım sürümü tarafından kullanılan üç ikili depo vardır:

  1. Kararlı (stable) depo
  2. Kararlı depo için test deposu
  3. Geliştirme (development) deposu

Bu ilk depo isminden anlaşılacağı üzere yayınlanmış olan kararlı Pardus sürümünün paketlerini barındırır. Bu depo sürüm çıkana kadar oluşturulmaz veya tümü ile boş bırakılır.

İkinci depo ise kararlı sürüme aktarılmak üzere hazırlanmış olan paketlerin test edildiği depodur. İkili paketler kararlı sürüm deposuna aktarılmadan önce bu test deposuna aktarılır ve test edilmeleri beklenir. Her paket için en az test süresi, depo sorumlusunun inisiyatifi saklı tutularak, 2 haftadır. Güvenlik güncellemeleri bu sınırın dışında tutulur.

Geliştirme deposu ise bir sonraki kararlı sürüm için hazırlanmakta olan PiSi paketlerini içerisinde barındırır.

İkili depo kuralları

Her depoda yapılacak güncellemelerde programlar arası ilişkilerin bozulmamasına azami önem göstermek gerekmektedir. API ve ABI'ın korunması esas olarak kabul edilir.

Kararlı depo üzerinde, yazılımların sürüm güncellemeleri ve depoya yeni bir yazılımın/paketin eklenmesi yalnızca deponun kararlılığını ve işlevini korumak için yapılır. Kararlı sürümde yapılan güncellemelerin amacı yeni özellikleri kararlı sürüme kazandırmak değil, sürümün kararlılığını korumak içindir. Yine de, eklenecek/güncellencek paket ile dağıtımın hedef kitlesine yönelik, yaygın bir kullanımın alanının sorunları gideriliyorsa depo sorumlusunun onayı ile işlem yapılır.

Bir kararlı depo içerisinde her hangi bir paketin yalnızca tek bir sürümü bulunabilir. Eğer yazılımların farklı sürümlerinin depoda bulunması gerekiyorsa bu pakete farklı bir isim verilerek çözülür. Örneğin; gtk1 ve gtk2 paketleri farklı paket isimleri ile depoda bulunmalıdır.

Depo isimlendirmesi

İkili depolar için aşağıdaki isimler kullanılır :

Kararlı depo

Her kararlı sürüm, sürüm adı ve sürümün ilk (major) numarasından oluşan bir depo ismi ile anılır. Örneğin; yayınlanmış olan Pardus 1.0 sürümü için ilk sürüm numarası "1" dir. Bu durumda ikili deponun adı "pardus-1" olacaktır.

Aynı ilk sürüm numarasına sahip her yayınlanan sürüm için kararlı depo aynı olacaktır. Yukarıdaki örnekten yola çıkarak 2007, 2007.1, 2007.2 depolarının kullanacakları kararlı depo "pardus-2007" olacaktır.

Kararlı depo için test deposu

Bu depo için, kararlı depo adının sonuna "test" son eki getirilir. pardus-2007 kararlı deposu için oluşturulan test deposu "pardus-2007-test" olarak adlandırılır.

Geliştirme deposu

Geliştirme deposu ise bir kullanım alanı için hazırlanan Pardus için her zaman aynı ismi alır. Örneğin; Pardus isimli işletim sistemi dağıtımı için geliştirme deposunun ismi her zaman "pardus-devel" olarak isimlendirilecektir. Bu isim, geliştirilmekte olan bir sonraki sürümün numarasından bağımsızdır ve tektir.

Depoya yeni bir paket eklenmesi

Paket depolarına yeni bir paket eklemek için bazı şartların yerine getirilmiş olması gerekmektedir. İki farklı depo (kararlı ve geliştirme) için farklı kurallar söz konusudur. Temel kural olarak yeni bir paket her zaman ilk önce geliştirme deposuna eklenir.

Bir paket geliştirme deposuna eklenmeden önce geçici olarak gözden geçirilmesi için playground/ deposuna review/ dizini altına eklenir ve paketler e-posta listesine e-posta ile haber verilerek gözden geçirilme süreci başlar. Gözden geçirme süreci paketin aşağıdaki kriterleri sağlayıp/sağlamadığı kontrol etmek için yapılır;

  • Paket sorunları:
o Oluşturulan ikili paketler fazla büyük (monolitik). Birden fazla pakete bölünebilir mi?
o Paketin actions.py ve pspec.xml dosyaları doğru formatta ve olması gerektiği gibi mi?
o Paket derlenirken dağıtımın belirlediği CFLAGS/CXXFLAGS/LDFLAGS gibi değişkenleri kullanıyor mu?
o Paketler inşa sırasında inşa dizini dışında işlem yapmadıkları kontrol edildi mi?
o Paketin inşa ve çalışma zamanı bağımlılıkları eksiksiz ve hatasız olarak listelenmiş mi? Paketin depoda herhangi bir çember bağımlılık yaratmadığı kontrol edildi mi ?
  • Yazılım sorunları:
o Utf-8 uyumsuzlukları var mı?
o Türkçe çeviri eksikliği var mı?
o Uygulama grafikleri masaüstü ile uyumlu mu?
o Ön tanımlı yapılandırma seçenekleri dağıtımın amaçları ile uyuşuyor mu?
o Yazılımın bilinen veya yeni bulunan hataları çözülmüş mü?
o Kullanışlılık sorunları mevcut mu?
o Paketin bilinen bir güvenlik açığı var mı? ( Varsa, ilgili güvenlik açığını gideren yaması ile birlikte eklenmelidir. )

Gözden geçirilen ve onay alan paketler Geliştirme deposuna eklenir. Fakat geliştirme deposuna eklenen tüm paketlerin ileride kararlı depoya ekleneceği garantisi yoktur. Kararlı depoya geçişe sürümün kuralları çerçevesinde kararlı depo sürdürme takımı karar verir.

Paket geliştiricileri için kurallar

Paket geliştiricileri subversion üzerinde bulunan kaynak deposu üzerinde çalışırlar. Yazılımların kaynak kodlarından PiSi paketlerinin oluşturulması için gerekli olan geliştirme, paket geliştiricileri tarafından yürütülür.

Geliştiricilerin sorumluluk sınırları

Paket geliştiricileri 3 farklı sorumluluk grubu ile listelenebilir :

  1. Depo sorumlusu: Depo sorumluları tüm depodan sorumlu olan ve tüm depo üzerinde işlem yapmaya yetkili kişilerdir.
  2. Bileşen sorumlusu: PİSİ kaynakları tasarım belgesinde anlatıldığı gibi bir bileşen tanımı yaparlar. Bileşen sorumlusu belirli bir bileşene uyan tüm paketlerden sorumu olan ve bu paketler üzerinde işlem yapma yetkisine sahip geliştiricidir. Örnek bileşenler arasında, system/base, system/devel, dekstop/kde sayılabilir.
  3. Paket geliştiricisi: Paket geliştiricisi yalnızca sorumluluğunu almış olduğu paketler üzerinde işlem yapma yetkisine sahiptir.

Sorumluluk grupları sorunların hızlı bir şekilde giderilebilmesi ve farklı boyutlarda kararların hızlı bir şekilde alınabilmesi için oluşturulmuştur. Herhangi bir geliştirici, sorumluluğunu aşan bir müdahale yapmak istediği zaman izin isteyerek çalışabilir. Üzerinde anlaşılmış konularda yapılan düzeltmeler/güncellemeler (örneğin uluslararasılaştırma, yerelleştirme ya da sözdizimi hataları gibi) genellikle izin istemeye gerek duyulmadan kabul edilir :).

Genel kurallar

  • Kaynak paket deposu üzerinde çalışan geliştiricilerin paket deposu kurallarına ve yayınlanmış bir sürüm zaman planı varsa bu zaman planına uyması gerekir.
  • Paket geliştiricileri hazırladıkları PİSİ kaynak dizinlerini oluştururlar, fakat PİSİ kaynaklarının .pisi ikili paketlerine dönüştürülmesi doğrudan paket geliştiricileri tarafından gerçekleştirilmez. Bununla birlikte, geliştiricinin kaynak paketi sisteminde oluşturduğu, test ettiği ve sorunlarından arındırdığı kabul edilir.
  • Geliştiriciler üzerinde çalıştıkları kaynak paket deposunun en güncel versiyonu ile çalışmak zorundadırlar. Bu hem kararlı sürümde, hem de geliştirme sürümünde yapılan çalışma için geçerlidir.
  • Geliştiriciler depoya gönderdikleri her paketten sorumludurlar, paketin derlenebilir, sorunsuz ve çalışır olduğundan emin olmak zorundadırlar. Paket tüm testleri geçmelidir.
  • Eksik veya tamamlanmamış paketler depoya asla gönderilmemelidir. Her paketin
pspec.xml, actions.py dosyaları doğru olarak yazılmış olmalı,
yamaları ve ek dosyaları files/ dizini altında bulunmalı,
ÇOMAR betikleri ise comar/ dizini içerisinde bulunmalıdır.
  • Paket depodaki hali ile derlenebiliyor ve kurulabiliyor olmalıdır.
  • Geliştirici aynı anda birden fazla paket ile ilgili depoya gönderim yapmamalıdır. Örneğin; bir geliştirici 8 paket üzerinde birden değişiklik yaptı ise, her paket için ayrı ayrı gönderimde bulunmalıdır (yani toplamda 8 ayrı gönderim). Kısaca gönderimler atomik olmalıdır.
  • Bir geliştirici bir başka geliştiricinin paketine acil durumlar dışında (güvenlik açığı, geliştiriciye uzun zamandır ulaşamama gibi) müdahale etmemelidir. Bu kural bileşen sorumluları için ise sorumlu olduğu bileşen dışındaki paketleri kapsamaktadır. Bunun yerine ilgili paket ile ilgili düzeltmesini paket sorumlusuna veya bileşen sorumlusuna göndermeli ve sorunun ne olduğunu ve nasıl çözüldüğünü ayrıntılı şekilde tarif etmelidir.
  • Depo'ya paket için gerekli yamalar, ek dosyalar veya post/pre betikleri, PSPEC dosyası, actions.py ve ÇOMAR betikleri dışında hiçbir şey konmamalıdır. Paketin kaynak kodu, geliştiricinin fotoğrafı ya da uygulamaya ait ekran görüntüsü de bu kurala dahildir :).

Paket isimlendirme kuralları

Paket isimlendirmesi ile ilgili kurallar pisi kaynak dizinindeki package_versions.tex belgesinde detaylı olarak anlatılmaktadır. Bu bölümde kısaca bir PİSİ paketinin isimlendirmesi anlatılacaktır. Bu kural serisine uymayan isimlendirmeler hatalı kabul edilir.

  • Bir pisi paketinin isimlendirme kuralı şu şekilde formülize edilebilir. PAKET-VERSİYON{_sonekNUMARA}-REVİZYON.
  • Paket ismi ana geliştiricinin pakete verdiği isimdir, değiştirilemez fakat genişletilebilir (kaynağının paketlenmesi sırasında oluşturulacak bir alt paket gcc-doc olarak isimlendirilebilir)
  • Paket versiyonu ana geliştiricinin pakete verdiği sürüm numarasıdır, değiştirilemez. (util-linuz-2.4z, kernel-2.6.9.4, gcc-3.3.6 gibi)
  • _sonek ile belirtilen kısım "alpha", "beta", "pre", "rc'" ve "p [patch level]" den biri olabilir. Bunların kendi arasında sıralaması şöyledir; :#alpha < beta < pre < rc < Son eksiz paket < p. (1.1_alpha1 < 1.1_beta1 < 1.1 < 1.1_p4 )
  • Revizyon geliştirici tarafından pakete verilen ve devamlı artan bir sayıdır. Pakete yapılan değişikliklerde bu revizyon numarası her zaman arttırılmalıdır.

Kararlı depo güncelleme politikası

Pardus kararlı sürümünün paketlerini içeren kararlı depoda yapılacak güncelleme ve geliştirme işlemleri, aşağıdaki politika çerçevesinde yürütülür. Bu depodaki her türlü işlem sürüm yöneticisi ve sürüm bakım takımı tarafından gerçekleştirilir.

Kararlı depo politikasını belirleyen problemler

Kararlı Depo Güncelleme Politikası belirlenirken ortaya konulan ve politika ile çözülmesi hedeflenen problemler şöyledir :

  • Kararlı sürüm içinde API/ABI bozmak ciddi sorunlara yol açabilir,
  • Kararlı sürüm için her şeyi güncellemeye çalışmak geliştirme sürecini baltalar,
  • Kararlı sürüm için hiçbir şey güncellememek ve her yeniliği geliştirme sürecinde yapmak kararlı sürümü baltalar,
  • Kararlı sürüme yeni özellik eklememek kullanıcıların kararsız sürüm kullanmasını tetikleyebilir,
  • Kararlı sürüme devamlı özellik eklemek sürümün kararlılığını bozabilir,
  • Depodaki her pakete aynı öncelikte/önemdeymiş gibi davranmak yanlış sonuçlar doğurabilir,
  • Depodaki güncellemelerin yeterince test edilmeden kullanıcıya sunulması ciddi sorunlar yaratabilir,
  • Alt seviye paketlerin güncellenmesi (glibc, gcc, binutils v.s) kararlı sürüm içinde ciddi değişiklikler gerektireceği için deponun branchlanmasını gerektirebilir,
  • Bu hızla depoya paket eklemek fakat aynı hızda geliştirici kazanamamak kontrolden çıkan bir depo yaratabilir,
  • Geliştirici başına düşen paket sayısının bu kadar fazla olması ciddi sorunlara yol açabilir,

Güncellemelerde Uyulması Gereken Kurallar

Yukarıda tarif edilmeye çalışan problemlerin en aza inmesini sağlamak amacıyla kararlı depoda güncelleme kural seti şöyledir :

  • Kararlı depo bir platformdur, desteklediği belli bir donanım seti, belli bir özellik kümesi vardır, Bu kümeyi sürekli arttırmaya çalışmak platformun kararlığını ve bütünlüğü bozar. Her yeniliği, her güncellemeyi bu platforma eklemeye çalışmak yeni bir dağıtım sürümünün çıkması demektir bu sebeple çok gerekli olmadığı durumlarda kararlı depoda güncelleme yapmak yasaktır.
  • Kararlı depoda ABI bozmak kesinlikle yasaktır,
  • Kararlı depoda API sadece kontrollü şekilde bozulabilir, API'nin bozulması gereken durumlarda API'yi bozmak isteyen geliştirici paketi depoya göndermeden önce neden bunun gerekli olduğu geliştirici e-posta listesine anlatmalı ve sürüm yöneticisinden onay beklemelidir.
  • Kararlı sürümün bakımını, hangi özelliklerin eklenmesi gerektiğini, hangi yeni paketlerin sürüme girmesini sürüm bakım takımı beraber belirler,
  • Sürüm yöneticisi ile çalışan birkaç kişiden oluşan "sürüm bakım takımı"nın onaylamadığı hiçbir güncelleme kararlı depoya giremez, bu takımdan başkasının kararlı depoya commit hakkı yoktur.
  • Sürümün kararlığını bozacak her güncelleme, deneysel özellik eklemesi yasaktır.

Yeni Paket Eklemelerinde Uyulması Gereken Kurallar

Depoya eklenecek yeni yazılımlar için kriterler şöyledir :

  • Kendi başına çalışabilen ve ek bağımlılık gerektirmeyen paketler, yerelleştirmeleri tam (oyunlar ve yerelleştirme ihtiyacı olmayan uygulamalar hariç) ve sorunsuz halde iseler sürüm bakım takımının onayı ile depoya girebilir.
  • Depoda bulunan bir paketle aynı amaca yönelik ikinci bir paket - çok uç bir durum olmadıkça- depoya eklenemez,
  • Bağımlılık ve/veya kullanışlılık açısından çok fazla ek paket getiren paketler çok gerekli olmadıkça depoya eklenmez.

Güncellemelerin öncelikleri

Depodaki paketlerin tamamına birmiş gibi davranmak yanlış sonuçlar doğuracaktır, bu sebeple paketler önemine göre kategorilere ayrılmış ve her kategoriye farklı öncelik verilmiştir. Bu kategoriler ve öncelikleri şöyledir;

  • Temel paketler: system/ bileşenin tamamını kapsar, burada yapılan herhangi bir güncelleme sürüm kritik hataya neden olabilir, bu sebeple system/ bileşeni ve altında paketler 1. önceliğe sahiptir ve burada değişiklikten sakınılmalıdır.
  • Temel KDE paketleri: desktop.kde.base/ altındaki paketler ve bunların direkt ters bağımlılıklarıdır. Buradaki paketlerin güncellenmesin ekstra özen istemektedir ve 2. önceliğe sahiptirler.
  • Temel Sistem kütüphaneleri: system ve desktop.kde.base altındaki paketlerin bağımlılıklarıdır, bu paketlerin güncellenmesi sırasında hiyerarşik olarak üstlerinde kalan paketlerin etkilenilmediğinden emin olunmalıdır, bu paketler 3. önceliğe sahiptir.
  • Çokluortam uygulamaları/kütüphaneleri: Tüm çokluortam bileşenleri bir arada ve uyumlu olmak olmak zorunda oldukları için buradaki değişikliklerin tüm seri ile uyum içinde olduğuna emin olunmalıdır, paketler 4. önceliktedir.
  • Çekirdek ve sürücüleri: Çekirdek güncellemeleri sistemi açılamaz hale getireceği için özellikle sakınılmalıdır, çekirdek tek başına 1. öncelikte bir paket iken, sürücülerinde güncelleme daha gevşek kurallar ile yapılabilir, çalışma ortamını etkilediği için buraya yeni sürücüler sürüm bakım takımının onayı ile eklenebilir.
  • Diğer sürücüler: Yazıcı sürücüleri, scanner sürücüleri v.s gibi kullanıcı katmanında olan sürücüler için bir arada düzgün çalıştıktıkları sürece sürüm bakım takımının onayı ile güncellemeler yapılabilir.
  • Kalan paketlerde yapılacak güncellemeler sürüm bakım takımının onayı ile yapılabilir.

Bu kurallar ışığında güncelleme türüne göre paketlerin öncelikleri şöyle özetlenebilir :

  • Güvenlik güncellemeleri depoya öncelikli olarak girecek paketlerdir.
  • Ciddi hatalar (veri kaybı, ciddi sorunlar v.s'ye sebep olanlar) depoya öncelikli olarak girecek paketlerdir.
  • Hata çözen güncellemeler depoya öncelikli olarak girecek paketlerdir.
  • İkili hale gelen paketler kullanıcının önüne güncelleme olarak gitmeden önce test deposuna girmeli ve gerekli testleri yapılmalıdır. Resmi ikili depoya sadece onaylanan ikili paketler girmelidir.
"http://tr.pardus-wiki.org/Pardus:Depo_Politikas%C4%B1" adresinden alındı.