[Gelistirici] mit-kerberos paketi check hatası

[Onur Küçük]

On Sun, 02 Jan 2011 16:48:19 +0200
Erdem Bayer <ebayer at pardus.org.tr> wrote:

> Selamlar
> 
> On Paz, 2011-01-02 at 15:33 +0200, Fethican Coşkuner wrote:
> >    Testi hiç bir zaman doğru çalışmayan bir pakete yazmanın bir
> > manası olmayabilir belki ancak patlamadan çalışanlar için kullanışlı
> > olabiliyor güncellemelerden sonra kontrol etmek açısından. Zaten
> > pakete
> > check eklemek paket sahibinin inisiyatifinde olan bir şey. 
> 
> Sanırım yazılan testler sadece o paket güncellendiğinde paketin düzgün
> çalışıp çalışmayacağını değil, depodaki herhangi bir değişiklik
> sonucunda paketin düzgün çalışıp çalışmayacağını test etmek içindir.

 Paket kaynak kodlarından çıkan testleri konuşuyorsak (make check)
tahminin doğru değil, sadece o yazılım için o testler, ki öyle de
olmalı. Yazılımların depo, bağımlılık vb. dertleri olmuyor, bir bakıma
olmamalı da. Bağımlılıkları ile ilgili bir şey yapılması gerekiyorsa da
bunu configure aşamasında yapıyorlar.

> Eğer paketlerin inşa aşamasında farm'a tüm paketler için paket
> sahibinin yazdığı testleri yoksay diyor isek (benim anladığım şu an
> durum böyle) hem paket inşa sistemimizin (örn: buildfarm) hem de
> paket yönetim sistemimizin (örn: check foksiyonu) amaçlarını ve
> çalışma prensiplerini yeniden düşünme vaktimiz gelmiş demektir.

 Farm vs. üzerine konuşalım ama testlerin sihirlii değnek olmadığını,
yanlış olabileceğini (ki malesef genelde yanlış oluyorlar), ana
geliştiricilerin yazdığı kodları adam etmek için uğraşmak zorunda
kaldığımızı, testler için de aynı durumun geçerli olduğunu unutmayalım.

 Burada make check diyince ifconfig le interface ayarlarını kurcalayan,
X'e bağlanıp pencere açıp bir bölümü seçmenizi bekleyen, sadece Almanca
yerelinde çalışan, yanlış olan ve ana geliştiricilerine bildirilince
"evet yanlış olduğunu biliyoruz ama onu kaldırmaya üşeniyoruz" yanıtı
alınan testlerin de olduğunu hatırlatayım.


> Birkaç örnek vereyim: (arada yanlış bildiklerim olabilir, eğer öyle
> ise lütfen düzeltin.)
> 
> * Ş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.

 Bunun için bir betik yazıldı, bunu farm koduna entegre edebiliriz, ama
şu anda tam bir çözüm değil.

> * 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.

 Farm da revdep-rebuild ile test ediliyor aslında, ha yeterli mi
derseniz değil.

> * 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)

 Doğru, bu ağır bir beklenti.

> * 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.

 Paket System.Package bacağı ile bayağı bir şey yapıyoruz, ama
geliştirilebilir, yanlış hatırlamıyorsam bir takım önemli eksikleri 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.)

 Bunu paketçisi paketin preremove  / postinstall unda çözebilir,
çözmeli de. Süper bir altyapımız yok şu anda, temiz bir şekilde
yapamadığımız durumlar oluyor, ama "yapılamaz" diyebileceğimiz bir
eksikliğimiz de yok.

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

 Evet hala eksiklerimiz var

> On Paz, 2011-01-02 at 15:43 +0200, Ozan Çağlayan wrote:
> > Paketçi, paketin test içerip içermediğini bilmeli, içeriyorsa bunu 
> >actions.py'ye ekleyip, paketinin bakımını yaparken testleri
> >çalıştırıp 
> > sorunları tespti edip çözülemesi gerekli olanları çözmelidir. Bazı 
> > paketlerin testleri 4-5 saat sürebiliyor, farmda testleri yaptırmak 
> > makul bir şey değil.
>  
> 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?
> 
> 4-5 saat süren bir testi paketçiye bırakmak demek o paketçinin yaptığı
> en küçük bir değişiklik için bile 5*6=30 saatini ve bu 30 saat boyunca
> sahip olduğu kaynakları harcaması demek. (O da sadece testin başarı
> ile sonuçlandığı durumda!)

 Paketçinin bu kadar zamanını alması doğru değil, bunun otomatik bir
sistemde yapılması doğru yol evet, ama Ozan gibi ben de (yarı) otomatik
diye bunun farmda yapılması gerektiğini düşünmüyorum. Bu iş için
ayrı bir altyapı olmalı, paketçi paketini orada test edebilmeli, farma
vermeden önce de farklı mimarilerde derleyip testlerini yapıp
sonuçlarını görebilmeli. Paketi farma vermek demek o paketin hazır
olduğu, kullanıcılara (hangi depo olduğu fark etmez) iletilebilir
olduğu anlamına geliyor. Bir paketin ilk testlerinin yapılması benim
aklımda bu aşamaya girmiyor. Şu anda böyle yapıyoruz doğru, ama
yapmasak daha iyi.

> 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

 make check öyle bir yapı değil

> 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.
> 
> 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.

 +1

> İşte tam da bu sebeplerden dolayı daha fazla ilerleyip iyice geri
> dönülemez noktaya gelmeden hem paket inşa sistemimiz hem de paket
> yönetim sistemimiz ile ilgili gereksinimlerimizi yeniden konuşmamız ve
> buna göre bir yol haritası çıkarmamız gerektiğini düşünüyorum.

 Bu göründüğü kadar basit bir konu değil baştan söyliyim, önce detaylı
bir şekilde konuşmamız lazım. Değişiklik yapmaya karar verirsek de ne
yapacağımızın adını net bir şekilde koymalıyız. Bunlar tamamlandıktan
sonra yol haritası vs. konularını konuşuruz.


-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens