[Gelistirici] Çakışma

Faik Uygur faik at pardus.org.tr
20 Kas 2006 Pzt 11:03:09 EET


19 Kas 2006 Paz 17:55 tarihinde, S.Çağlar Onur şunları yazmıştı: 
> şeklinde hata aldım, buildhouse'da kurulu  pisi (pisi 1.1_rc7) bu çakışmayı
> çözemedi (versionFrom/To conflictler yüzünden)

Bu pisi'nin geliştirme sürecinde kırıldığı anlamına geliyor. Bu kırılmanın rc 
sürümlerine denk gelmesi hoş olmadı. Yine de rc hala geliştirme sürümü 
sayılabilir. Stabil sürüm içinde ise böyle bir şey kesinlikle ve kesinlikle 
olmamalı. pisi up her zaman çalışmalı.

> ve önce pisi up pisi ile pisi'yi güncelleyip sonra sistemi güncellemek
> zorunda kaldım, bu hal durumu pisi'de çözsek nasıl olur? Listede pisi varsa
> pisi önce system.base ve kendini güncellese, açık hatası olduğunu biliyorum
> ama bu sefer problem oradaki hatadan farklı

Karşılaşılan sorunun çözümü pisi önce kendini güncellesin olsun bitsin olarak 
göründüğünün farkındayım. Listede pisi varsa - system.base ve pisi öncelikle 
güncellensin - işin en kolay kısmı, zor kısmı ise güncellemeye yeni pisi ile 
sorunsuz devam edilebilmesi. Bu işi düzgün yapabilen/yapan bir paket 
yöneticisi olduğunu zannetmiyorum. [1] [2] 

Python'da ise bu iş, iki ucu çamurlu değnek diyeyim. Framework'ün içindesiniz, 
bu işi yaptığınız yer framework'ün dışında olmalı bir kere. Yoksa reload 
yaptığınız kısım framework'ün içinde ise heryeri güncelleseniz 
çalıştırdığınız yer eski pisi'den. Burası operations.py gibi bir yer olmamalı 
mesela. Redhat'daki up2date benzeri ayrı bir dış betik'den belki yapılabilir.
Belki biraz zorlarsak pisi-cli commands kısmından yapılabilir. Ayrıca 
package-manager'da da bu işin ayrı bir şekilde handle edilmesi gerekiyor. 
package-manager'da reload edecek herşeyi. Comar, package-manager için asıl 
pisi'yi çalıştıran olduğu için, hani önce system.base ve pisi upgrade et 
komutu ardından, kalanları upgrade et komutu gönderdiğinde ayrı ComarJob 
processleri çalışacağı için kurtarır gibi görünüyor ama package-manager da 
pisi.api kullanıyor. ComarJob işi öncesi generate_conflicts, 
generate_upgrade_order ve generate_install_order gibi api işlemlerini 
kullanıyor. Bu yüzden o da kendi içinde pisi framework'ünü update etmeli. 
Yani hem pisi-cli, hem package-manager tarafında ayrı çalışmak gerekiyor.

Python'da reload işleri de pek kolay değil. reload sırasında "from import"'lar 
ile ilgili sıkıntılar var. [3] pisi "from import" dolu. Şu anda operations.py 
de Version class'ı ve rebuild-db için yaptığımız reload işi bu işin en 
doğrusu gibi görünüyor. Ama buna rağmen halen o koda tam olarak 
güvenemediğimi söyleyeyim.

Sonuç olarak package-manager ve pisi de yapacağımız değişikliklerin ciddi ve 
sorunlara gebe değişiklikler olacağını ve bunların testleri için yeterli 
zamanımızın kalmadığını düşünüyorum. Zaman olsa bile bu işi yukarı da 
anlattıklarıma dayanarak yapma taraftarı olmadığımı söylemek isterim. 

-- 
- Faik

[1] 
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-upgrading_aptitude

[2] 
http://fedoraproject.org/wiki/YumUpgradeFaq#head-bee4591f4bebe867a1cfbbef57475418fe6bc228
(Ki adamlar release'ler arası açık açık biz live upgrade i tavsiye bile 
etmiyoruz diyorlar.
(http://fedoraproject.org/wiki/YumUpgradeFaq#head-bdd1ed4a339aa22c95c238af0e3323c0bccf6167)  
İlla upgrade edeceksen, installerdaki bizim upgrade'imizi kullan diyorlar. 
Orada da ne taklalar attırdıklarını kim bilir.

[3] 5.7.5 ve 5.7.6 ncı bölümler 
http://www.leftworld.net/online/Python/lpython_snode60.html 



Gelistirici mesaj listesiyle ilgili daha fazla bilgi