[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