[Gelistirici] Çomar ve Yanlışlar

[Gökçen Eraslan]

On Monday 20 December 2010 08:43:20 Gökmen Göksel wrote:
>  - Model dosyaları comar paketinden geliyor, modelde bir değişiklik yapmak
> ya da model üzerinde bir değişiklik yapmak için comar paketinin
> güncellenmesi gerekiyor.
> 
>  - Model dosyalarında olduğu gibi haliyle policy dosyaları da (PolicyKit
> için) comar paketinden geliyor. Aynı problem burada da var.
> 

Modellerin paketlerden değil de COMAR'dan gelme nedeni sanırım aynı işlevi 
örneğin ağ işlemleri yapan 2 alternatif paketin aynı modeli sağlayabilmesi ve 
istenen durumda, istenenin tercih edilebilmesiydi. Yani COMAR sabit bir 
API/Model tanımlar, isteyen her paket bu Modeli sağlayan bir bacak taşır. 
İsterse birden çok paket de aynı modeli sağlayacak şekilde bacak taşıyabilir. 

Mesela bir nedenden hem kendi ağ yönetim altyapımızı geliştirmeye devam ediyor 
olsaydık hem de Gnome NM kullanmak durumunda olsaydık, Gnome NM ve Pardus NM, 
COMAR'ın Ağ Yönetimi için tanımladığı Model'i sağlardı ve 2009'da 
kullandığımız kendi arayüzümüz (teorik olarak) hiç değişikliğe uğramadan, 
sistemde Gnome NM kuruluysa onunla, Pardus NM kuruluysa da onunla 
çalışabilirdi. Modellerin COMAR'dan gelme nedeni bu. Bence, _manager'ların 
COMAR kullanmaya devam edeceğine karar verirsek_, Modellerin ve policylerin bu 
şekilde COMAR'da durması, olması gereken bir davranış. Belli bir olgunluğa 
eriştiğinde artık modellerde çok fazla değişiklik olmuyor, isterseniz bakın 
model dosyalarına ne sıklıkta commit gelmiş.

>  - Çomar bacakları konu ile ilgili olduğu düşünülen paketlerden çıkıyor ki
> bu  bacaklardaki en ufak bir değişiklikte de aynı problem ortaya çıkıyor;
> Boot.Loader bacağındaki bir değişiklik için grub paketi güncellemeniz
> gerekiyor.
> 
> Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile
> dağıtılan  model/policy dosyaları için ilgili çomar bacağını ifade eden
> başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli
> uygulamalara bu paketler için bağımlılık yazalım.
> 
> Bu şekilde bir düzene geçtiğimiz taktirde, mevcut manager-* aliemizin
> başka  dağıtımlarda kullanılabilmesi için şu anda zorunlu olan çomar
> bağımlılığından da rahatlıkla kurtulabiliriz; diğer dağıtımlar için
> hazırlanacak pakette, çomar bacaklarının KAuth için uygun hale getirilmesi
> ve söz konusu manager'ın yanında dağıtılıyor olması yeterli olacaktır.

Ben de, manager'ların diğer dağıtımların kullanabileceği şekle sokulmasını 
istiyorum ama doğru çözümü bilemiyorum. Üzerine daha fazla düşünmek lazım. 
Manager'ları COMAR'dan ayırmak için, bacakları site-packages'a herhangi bir 
kitaplık olarak gönderip, DBus aktivasyon ile çalışan wrapper'ler yazıp, 
Manager'ları bu wrapper'ları kullanacak hale getirebiliriz. O zaman örneğin 
User Manager, tr.org.pardus.UserManager arayüzünün addUser method'unu 
çağırdığında doğrudan bacak işini yapar ve kullanıcıyı ekler ve bu, wrapperlar 
ile manager kodları ayrı olduğu için abstraction da sağlar, fakar COMAR'ın 
modellerinden daha ince bir abstraction sağlar. 

Bu yaklaşımı yukardaki hayali Pardus NM / Gnome NM senaryosunu çözmek için 
kullanmak daha zor olur, çünkü COMAR modeli, bacağı, o modeli implement etmeye 
_zorluyor_. Ama sadece DBus aktivasyonla çalışan ayrı betikler haline 
getirdiğimizde bir bacağın _tam olarak_ neleri sağlaması gerektiğiyle ilgili 
bir kısıtlama olmayacak. Tabi bu kısıtlamalara ve geniş abstractionlara ne 
kadar ihtiyacımız var onu bilmiyorum.

-- 
Gökçen Eraslan
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20101221/3671fd5f/attachment-0002.pgp>