[Gelistirici] mit-kerberos paketi check hatası

Ozan Çağlayan ozan at pardus.org.tr
2 Oca 2011 Paz 19:36:31 EET


On 02.01.2011 19:03, Erdem Bayer wrote:
> Selamlar
>
> Hayır, kitaplık olmak zorunda değil, php paketindeki bir güncelleme
> mod_php kullanan bütün paketleri etkileyebilir. Şu anki durumda Php
> paketi her güncellendiğinde phpmyadmin paketinin sahibinin paketini yeni
> derlenen php ile test etmesini belkiyoruz/istiyoruz, ancak bunu
> gerçeklemek mümkün/olanaklı değil.
>
> Paket sahibi paketinin bağımlılıklarında her değişiklik olduğunda
> kendisi paketlerini yeniden inşa edip test edecekse, paket inşa etmekten
> başka birşey yapmaya vakit bulamayabilir. Halbuki bunun yerine bir paket
> güncellendiğinde hem kendisini hem de bütün ters bağımlılıklarını bu işe
> tahsis edilmiş bir alanda 3 dağıtım ve iki mimaride inşa etsek,
> paketçiye bu inşa edilmiş paketi haber versek, al test et desek herkes
> daha verimli çalışmış olmaz mı?

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

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

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

>
> Yakın gelecekte üç farklı mimari üzerinde çalışacağız, gerçekten hiç
> ihtiyacımız olmayacağından emin miyiz diyorum ben de.

Hayır değiliz ancak ihtiyacımız olduğunda elimizde 2-3 alternatif çözüm 
var diyorum :)

>
> Evet, aklımdaki yapı tam bu.

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

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

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



Gelistirici mesaj listesiyle ilgili daha fazla bilgi