[Gelistirici] preRemove metodu

[Fatih Aşıcı]

 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 :(