[Gelistirici] Pisi delta iyileştirmeleri

[Faik Uygur]

Salı 03 Şubat 2009 günü (saat 12:36:59) Gökçen Eraslan şunları yazmıştı:
> Selamlar,

Elinize sağlık,

> Bu noktada şöyle bir durum var, binary dosyalar, kodlarında bir değişiklik
> olmasa dahi her derlendiklerinde farklı SHA1'lere sahip oluyorlar. Yani
> aynı kodu tekrar tekrar derlediğinizde (teknik detaylarını tam bilemiyorum,
> linklendiği kitaplıkların offset'lerinden ya da dosya içine yazılan bir
> timestamp'ten olsa gerek) üretilen her dosyanın SHA1'i farklı oluyor. 

[...]

> 1- Yeniden derlenen iki binary'nin, kaynak kodunun değiştiği için mi yoksa
> sadece yeniden derlendiği için mi farklı olduğunu kestirebilir miyiz?
[...]
>  1a- Eğer, ekstirebilirsek, SHA1'i farklı olan fakat aslında sadece tekrar
> derlenmiş olan binary'leri deltaya almayız.

Bilemiyorum ben de, araştırabiliriz.

>  1b- Kestiremezsek, şöyle bir şey düşündük, değişen dosyaların tamamını
> delta paketine almak yerine, eskileriyle olan xdelta'larını delta paketine
> alabiliriz. Bu şekilde baya bir azalma sağladık delta paketlerinde.

Mümkündür. İlk delta paketini xdelta ile yapmaya başlamıştık. Önceki 
indirilmiş paketin saklanması gerekliliği ve lzma geçisi sonrası xdelta 
lzma'yı anlamaz hale de gelince zorunlu bu çözüme gitmiştik. İsmail bu konuda 
xdelta'ya bir hata girmişti. [1] Geliştiricisi en son sıkıştırılmış dosyalar 
için şuraya yönlendirmiş. [2] Fakat performans açısından önerdiği hiç de uygun 
değil. Şu anki delta paket yapımız performans olarak da çok çok iyi. Tek 
yaptığı dosyaları sisteme açmak.

> Örneğin, değişen dosyalar yerine sadece eski ve yeniler arasındaki
> xdeltaların olduğu ati-control-center paketinin boyutu, 5.5M'tan 1.4M'a
> düştü.(İlgili yamayı ekledim) Bu durumda da şöyle bir sıkıntı çıkıyor,
> delta paketini kurarken, eğer eski dosyanın aynısını sistemde bulamazsak
> güncellemeyi hiç yapamıyoruz. 

Bu bulunmalı tabi. Şu anki delta paketi için de aynı sorun var sayılabilir ama 
güncelleme esnasında bu bir probleme yol açmıyor. Bir paketin eksik dosyaları 
varsa ya da silindiyse o paketin çalışmaması bekleniyor sadece. Sıradan bir 
paket kurup, dosyalarını silmek gibi.

xdelta durumunda pisi bu dosyalar üzerinde özel bir komut çalıştıracağı için, 
ek kontroller yapılmalı, güncellemenin xdelta'ya bağlı olarak başarılı ve ya 
başarısız olmasına göre ne yapılacağı kararlaştırılmalı. Ya hiç bi şey olmamış 
gibi devam edecek ya da güncelleme sonlanacak.

> Bunun da üstesinden gelmek içinse, şöyle bir
> şey yapılabilir, güncelleme yapılmadan önce paket "pisi check" ile kontrol
> edilir, "pisi check" o paket için sorunsuz tamamlanırsa, bu eski paketin
> aynen sistemde olduğu ve xdeltanın dosyaya uygulanabileceği anlamına
> geliyor, dolayısıyla ufak boyutlardaki delta paketini kurabiliriz. "pisi
> check"te sorun çıkarsa da, delta yerine depodan gerçek paket kurulur.

Güncellemeye başlamadan önce bir paketin delta paketini indirip, indirmeyeceği 
kontrolü bu şekilde çok uzun sürer.

faik at jupiter pisi $ time pisi check kernel-source
* kernel-source kontrol ediliyor... Tamam

real    3m24.959s
user    0m15.321s
sys     0m6.122s

faik at jupiter pisi $ time pisi check kernel-source
* kernel-source kontrol ediliyor... Tamam

real    2m15.123s
user    0m15.406s
sys     0m5.838s

Şu an delta paket yapımız çok sade ve basit. Herhangi bir paketten farkı yok. 
Bu hoşuma gidiyor. Paket içini açıp dosyaları da inceleyebiliyoruz.  xdelta 
ile bu mümkün değil. Delta'da iyileştirilebilecek bir şeyler mutlaka 
bulunabilir. Örneğin 1a'ya bakabiliriz. Ama buradaki öneri daha şu anki halini 
kullanmaya başlamadan çok erken ve köklü bir değişiklik bence.

- Faik

[1] http://code.google.com/p/xdelta/issues/detail?id=1&can=2&q=
[2] http://code.google.com/p/xdelta/wiki/ExternalCompression