[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