[Gelistirici] mit-kerberos paketi check hatası

[Ozan Çağlayan]

On 02.01.2011 16:48, Erdem Bayer wrote:
> Selamlar

>
> * Şu anki paket inşa sistemimiz runtime bağımlılıkları çözebilmek için
> bütün paketleri inşa ettiği alana kuruyor, dolayısı ile bir paketin
> bağımlılıkları doğru yazılmamışsa farm'ın bunu yakalama ve uyarma şansı
> olmuyor.

Bu sadece, bağımlılık olarak yazılmamış *ancak* farmda tüm paketler 
olduğu için derleme esnasında bulunarak bağlanılmış dinamik 
kitaplıkların kullanıcı sisteminde kurulu olmamasından dolayı olası 
kırılabilme sorunlarını çözer. Yani paket bağımlılıkları doğru 
yazılmamışsa farm'ın bunu yakalaması ve uyarmasıyla birebir ilintili 
değil. Ama yine de şu anki tüm paketleri üstüne kurma mekanizması da 
sağlıklı bir mekanizma değil, bunu herkes kabul ediyor.


>
> * A paketinde bir değişiklik olmuş ise, A paketinin tüm ters
> bağımlılıklarının bu değişiklikten etkilenip etkilenmedikleri test
> edilmiyor. Bu testi yapmasını sınırlı kaynağı ve zamanı olan paket
> sahibinden bekliyoruz.

Değişikliğe göre değişir. Bu A paketi bir defa kitaplık olmak durumunda. 
Kitaplık olmadığı durumda A'daki değişikliğin geriye yayılarak sorun 
çıkarmasını anlamanın tek yolu paketçinin durumdan haberdar olmasıdır.

A kitaplığının sürümü yükseldiyse, ona bağlanmış paketlerin kırılması 
durumunda buna yaptığımız bir şey maalesef yok, ancak kırıldıktan sonra 
sürüm yöneticisi paketçiyi uyarıyor.

>
> * Paketçiden bir pakette yapılan ufak bir değişikliği bile 3 farklı
> dağıtım ve iki mimari üzerinde kendi başına inşa ve test etmesini
> bekliyoruz. (Yine sınırlı kaynak ve zaman problemi)

Buna nasıl bir çözüm bulunabilir bilmiyorum. Sonuçta paketçi bu ufak 
değişikliği test edecekse zaten 3 farklı dağıtım ve 2 mimarinin 
halihazırda önünde olması lazım. Bu durumda da pisi bi pspec.xml ile 
paketi oluşturup kurması çok da zor değil. Ha test etmeyecekse zaten 
etmiyor ve commit edip geçiyor.

>
> * Paket yönetim sistemimizin bir paketi güncellemekten anladığı şey
> paketin eski sürümünü kaldırıp yeni sürümünü kurmak. Bu durum paketin
> güncellenme aşamasında yapılması gereken özel birşey varsa elimizi
> kolumuzu bağlıyor.

postInstall, preRemove var?

>
> * Paket yönetim sistemimiz içinden servis betiği çıkan paketleri servis
> ile ilgili herhangi bir işlem yapmadan kaldırıyor, daha sonra yeniden
> kurmaya çalıştığında (örn: güncelleme) karşılaşılan bir hata sistemi
> geri dönülmez durumda bırakabiliyor. Örn: Paket kaldırıldı, ancak servis
> durmadığı için yeniden kurulamıyor, artık paket de gittiği için servisi
> durdurmanın herhangi bir yolu da yoksa ne yapacağımızı şaşırabiliyoruz.
> (Teorik bir örnek değil, geçen gün eski bir makine üzerinde nfs-server
> paketini güncellerken başıma geldi.)

Bundan dolayı oluşan bir sorunla hiç karşılaşmadım şu ana kadar ancak 
RPM paketlerinde gerçekten de aç/kapa yapılıyor. Bunu mevcut PiSi 
altyapısıyla yapmak oldukça kolay olmalı.

>
> * Paketlerimizin farklı mimarilerde farklı ihtiyaçları var ise (örn:
> farklı bağımlılıklar) bu ihtiyaçları karşılayamıyoruz veya karşılamakta
> zorlanabiliyoruz.

Hiç karşılaşmadık. Karşılaşılınca nasıl çözüleceğine dair geliştirici 
listesi arşivlerinde yapıcı bir tartışma var zaten oradaki çözümlerden 
birini uygulamak sorunu çözecektir.


> Bazı testler 4-5 saat sürebiliyorsa bu testlerin yapılmasının yeri bence
> elle yapılan bir inşa yerine tam da otomatik çalışan bir sistem olan
> farm olmalıdır. Uzun süren işlemi otomatik çalışan uygulamaya değil de
> elle çalıştırılan ve kişisel çalışma ortamlarımızın kaynağını harcayan
> bir yönteme bırakmak sadece bana mı mantıksız geliyor?

Hayır. Zaten mevcut sıralı paket derleme mekanizması yerine dağıtık ve 
asenkron bir yapı olsa testler açılabilir. Şu anki tüm paketleri sırayla 
derle, üstüne kur mantığı yanlış olduğu için bu yanlışın üstüne testler 
de açılırsa paket derleyemeyiz.

Bir de dipnot, PiSi kodunun düzeltilip check() fonksiyonunun dönüş 
değerine göre hata değil uyarı vermesi gerekiyor. check() paketin 
oluşumunu engellememeli.

Bir de her şeyi düzgün yapsak, sandbox'a takılacak bir sürü test olacaktır..

>
> Ayrıca yukarıda yazdığın cümle her ne kadar doğru gözükse de yazılan
> testlerin sadece o paketle ilgili olmadığı, paketin bağımlı olduğu diğer
> tüm uygulamalar ile o paket arasındaki ilişkiyi de kontrol ettiğini
> düşündüğümüzde testlerin sadece o paket üzerinde bir değişiklik
> yapıldığında değil bağımlılıkları içinde bir değişiklik olduğunda da
> çalıştırılması gerekliliği ortaya çıkıyor, bunu da paketçiye bırakmanın
> insafsızlık olduğunu düşünüyorum.

Bu çok over-engineered bir senaryo bence.

>
> Ayrıca testler dışında inşası uzun süren paketler de var, yine bu
> paketlerde yapılan en ufak değişikliği de 6 ayrı yerde inşa ederek test
> etmesini paketçiden bekliyoruz, halbuki bunu otomatik yapabilen bir
> yazılım var ise bu da bana insafsızlık gibi geliyor.

Evet bu gerçekten hoş olur.

Bunun için,

* Dedicated/güçlü bir sunucu altında bir sanallaştırma teknolojisiyle 
sanallaştırılmış len(dagitim)*len(desteklenen_mimari) kadar derleme 
çiftliği oluşturulmalı.

* Derleme yazılımı kendisine uzaktan gelen istekleri bu çiftliklere 
paslamalı ve bu çiftliklerde her paketi izole temiz rootfs içinde 
derlemeli (Sorun 1: A paketi B'nin yeni sürümüne inşa bağımlı ise, A'nın 
derleneceği ortamda, B'nin yeni sürümü kurulu olmalı. Bu nasıl olacak?). 
Bu esnada testler de çalışmalı.

* Düzgün bir web arayüz. Ama gerçekten düzgün. Her şeyi anlatan, sunan, 
test sonuçlarını görüntüleyen, paketleri indiren linklerin olduğu, vs.vs.

* Paketleri derletme isteklerini göndermek için konsol araç kiti.





-- 
Pardus Linux
http://www.pardus.org.tr/eng