[Gelistirici] preRemove metodu
Fatih Aşıcı
fatih at pardus.org.tr
3 Kas 2010 Çar 19:10:42 EET
On Wed, 03 Nov 2010 09:12:51 +0200, Fatih Aşıcı <fatih at pardus.org.tr>
wrote:
> On Tue, 02 Nov 2010 23:28:57 +0200, Ozan Çağlayan
> <ozan at pardus.org.tr> wrote:
>> Merhaba,
>>
>> preRemove'da kurulu paketin sürüm, release bilgisine ihtiyaç duyulan
>> paketler var docbook ailesinde. Şu an 2 pakete baktım, ikisinde de
>> hardcoded bu bilgiler bu yüzden mass rebuild esnasında release
>> arttığından postInstall preRemove'lar kırılıyor hep. docbook'larla
>> ilgili yaşadığımız bir sürü sorun bunlarla ilgili olabilir.
>>
>> preRemove'da da bu bilgiyi sağlayabilir miyiz kısa bir süre içinde?
>> Ya da neden yapmamışız?
>
> preRemove'da bu bilgilerin sağlanmasının bir anlamı yok aslında. Asıl
> ihtiyaç
> duyduğun şey {pre,post}Upgrade metodları. Bu metodları postInstall'a
> benzer şekilde
> sürüm bilgileriyle eklemeyi düşünüyorum. Geriye uyumluluğu sağlamak
> için de öntanımlı
> gerçeklemeleri yerine göre {pre,post}Remove, postInstall vs.
> çağıracak.
{pre,post}Upgrade fonksiyonları bu işi daha da karıştıracak gibi
görünüyor.
{pre,post}Remove fonksiyonlarına postInstall'da olduğu gibi parametre
geçmek
daha temiz görünüyor; ancak Çomar bağımlı olduğumuz için geriye
uyumluluğu
bozmadan fonksiyonun imzasını değiştirmek kolay görünmüyor.
Bir paketin yeniden kurulması, güncellenmesi ve eski bir sürüme dönmesi
arasında Pisi açısından bir fark yok. Hepsinde de preRemove, postRemove
ve
postInstall çağrılıyor. RPM, bu işlemler arasındaki ayrımı betiğe işlem
sonundaki
kurulu sürüm sayısını geçerek çözmüş. Böylece betiklerde hangi işlemin
yapıldığı
anlaşılıyor.
Yine PackageHandler betikleri içinde paketin ilk kurulumu ile
güncellemesi
arasında bir ayrım yapmak mümkün değil. Gereksiz yere tekrar tekrar
depmod
çağırıyoruz mesela.
Çomar bağımlılığını atıp bu işleri daha esnek bir hale getirmek lazım;
ama bu da
uzun sürecek bir iş malesef :(
Gelistirici mesaj listesiyle ilgili
daha fazla bilgi