[Gelistirici] mit-kerberos paketi check hatası

[Erdem Bayer]

Selamlar

Paz, 2011-01-02 tarihinde 21:27 +0200 saatinde, Onur Küçük yazdı:
>  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.

Hayır actions.py içindeki check() fonksiyonunu konuşuyoruz. Ben paketçi
olarak bu paket inşa edilirken birşeylerin kontrol edilmesini istiyorsam
(bu make check de olabilir, paketçinin insiyatifi), ve farm paketi inşa
ederken de benim bu isteğimi yoksayıyorsa birimiz hata yapıyoruz
demektir.

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

Aynı durum biz de geçerli, biz de "testlerin yanlış olduğunu biliyoruz,
ancak bu yanlış olduğunu bildiğimiz checkleri kaldırmaya üşeniyoruz,
dolayısı ile sadece farmda çalışmasını engelliyoruz" diyoruz. Biz de ana
gelişticilerden daha iyi durumda değiliz.

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

Bkz. son paragraf

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

Bkz. son paragraf

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

Bkz. son paragraf

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

Bkz. son paragraf

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

Bkz. son paragraf

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

Ben de aynen bunu diyorum, bunu detaylı bir şekilde konuşalım. Hafta içi
ilgilenen herkesle bir toplantı mı ayarlayayım, yoksa burada tartışmaya
devam mı edelim. Hangisi daha pratik olur emin olamadım.

Saygılarımla
Erdem Bayer