[Gelistirici] mit-kerberos paketi check hatası

[Erdem Bayer]

Selamlar

Paz, 2011-01-02 tarihinde 19:36 +0200 saatinde, Ozan Çağlayan yazdı:
> "phpmyadmin paketinin sahibinin paketini yeni derlenen php ile test 
> etmesini bekliyoruz/istiyoruz" demişsin. Evet istiyoruz ama sunduğun 
> çözümün sonunda yine phpmyadmin paketinin sahibi paketini yeni php ile 
> test etmeyecek mi?
> 
> Yani test etmekte bir getiri yok sadece derlemekten kurtulabilir.

Hayır, söylediğim şey paketleri test edebilmek için inşa etmenin test
etmekten daha zor olduğu ve her zaman her geliştiricinin elinde yeterli
kaynağın bulunmayabileceği. Geliştiricilerin paketlerinin otomatik
ortamlarda inşa edilmesi paketçinin üzerindeki yükü hayli azaltır demek
istiyorum.

> 
> >
> > postInstall ve preRemove fonksiyonları paket güncelleme (kaldırıp kurma
> > değil) aşamasında özel birşey yapılması gerekiyorsa nasıl yardımcı
> > oluyor? Örneğin bir paket güncellenirken (ama sadece güncellenirken)
> > yapılması gereken birşey olduğunda postInstall ve preRemove'u nasıl
> > kullanacağız, açıklanırsa iyi olabilir.
> 
> güncelleme ve sıfırdan kurma arasındaki farkı yaratacak bir detay 
> bulunuyor genelde paketlerde. fromVersion ve fromRelease string'leri boş 
> değilse güncelleniyor demektir. Zaten bu pre/post hikayelerini daha 
> düzgün bir şekilde Fatih tekrardan yazıyor/yazacak diye biliyorum.

Peki.

> 
> > Mevcut pisi altyapısı ile ne kadar kolay olacağını bilmiyorum, ancak
> > servis durmadı ise paketi kaldırmaması (ve hatta bağımlılıklara da
> > elleşmemesi, dolayısı ile indirme işleminden sonra ancak tüm
> > kaldırma/güncelleme işlemlerinden önce çalışması gerekiyor),
> > güncellemeden önce servis çalışıyor ise güncellemeden sonra da yeniden
> > çalıştırması gibi gereksinimlere dikkat etmek gerekiyor.
> 
> Güncellemeden önce durdurup sonra başlatmaya ACK, bu dediğin senaryoya 
> NACK. Çünkü bu dediğin işleyiş gerçekten gerçeklenesi bir mekanizma 
> değil, çok zor, çok alengirli, bir çok şeyi kırabilir. Servis o anda 
> kapanmamayı seçiyor olabilir, vs.vs. Bir de bu aç/kapa bence bir ayara 
> bağlanmalı. Görev kritik hizmet sunan sunucular güncelleme esnasında 
> servislerin sorgusuz sualsiz aç/kapa yapılmasından zarar görebilirler.

Görev kritik hizmet sunan sunucular kendiliklerinden güncellenmezler. Bu
sunucuların güncellemeleri sistem yöneticisinin yapacağı plan dahilinde
olur. Görev kritik sunucularda servisi kapatmadan güncellemek bence hiç
güncellememek kadar kötü bir senaryo.

ACK dediğin senaryo, NACK dediğin senaryoya göre daha fazla sorun
çıkarır. Eğer güncelleme öncesi servisin durmasını istiyorsak ve
durmuyorsa bu güncellemeye başlamamız için bir işaret değil midir
(Servis durmayı reddediyorsa bir probleme işaret ediyor olamaz mı?) Eğer
kullanıcı servis durmasa bile güncelleme yapmak istiyorsa
--ignore-service-check gibi bir parametre ile yine de güncelleme
yapabilir.

Bir şeyi yapacaksak ilk sefer doğru yapalım, bunu yapmak çok alengirli
diye daha çok sorun çıkaracak bir çözüme gitmeyelim. Evet, yapılması
daha zor olabilir, daha uzun sürer, daha çok kişi daha çok emek harcamak
zorunda kalır ancak uzun vadede daha faydalı olur. 

> 
> Aslında bu bir çok insanın aklındaki yapıdır büyük ihtimalle. Fedora da 
> bu yapıyı kullanıyor. Ancak sıfırdan oturup yazması gerçekten çok zor 
> hele ki aramızda web ile ilgilenen, bütün vaktini bir süreliğine bu işe 
> verecek birisi yok iken.
> 
> O yüzden ben Fedora/Koji örneğinden gidilip teknoloji koji, altyapı pisi 
> olan bir yeni ürün çıkartılması taraftarıyım. Mevcut koji kodunun 
> incelenmesi ve sindirilmesinden sonra pisi desteğinin eklenmesi çok da 
> zor olmamalı.

Geçen hafta koji altyapısına bakmıştım, koji her inşa aşamasında yeniden
özel sistem kuruyor, ve çalışmasının her aşaması yum/fedora bağımlı.
Maalesef çalışma süreçleri de bizim dağıtım süreçlerimize uymuyor.

koji biraz daha derinden bakıldığında dağıtık yapıda çalışabilen bir rpc
sunucusu. Benzer birşeyler Pardus için de yapılabilir.

> 
> Bir de OBS (Opensuse build service) var. Ona hiç bakmadım.
> 

Ben baktım, dağıtım süreçlerimiz ile daha uyumlu (çünkü daha esnek),
paketçi inşa tanımını kendisi yaptığı için de son derece esnek. Ancak
onun da kendine özgü problemleri var.

İkisinin de beğendiğimiz özelliklerini barındıran bir servis sanırım en
iyisi. Bu thread'in bir amacı da böyle bir serviste hangi özelliklerin
bulunmasını istiyoruz sorusuna cevap bulmak olduğundan diğer
paketçilerin/geliştiricilerin de yorumlarını bekliyorum.

Saygılarımla
Erdem Bayer