[Gelistirici] Gnome ActionAPI

Eren Türkay turkay.eren at gmail.com
1 Tem 2007 Paz 00:46:10 EEST


On Sun, 1 Jul 2007 00:26:29 +0300
"S.Çağlar Onur" <caglar at pardus.org.tr> wrote:

> Eğer ciddiysen bu argüman kabul edilebilir bir argüman değil ne yazık
> ki, burda birkaç sorun var;
> 
> a) --disable-scrollkeeper veya atıyorum "export 
> GNOME_SUCKS_SO_DISABLE_SCROOLKEEPER=1" çalışmıyorsa
>  
> GNOME ve ilgili paketlere hata bildirmek/neden çalışmadıklarını
> analiz etmek ve çözmelerini sağlamak gerekiyor
> 
> b) Eğer biz hatalı kullanıyorsak doğrusunu öğrenmek ve onu kullanmak 
> gerekiyor.
> 
> c) actionsAPI'de her paketin saçma sorunlarını çözmek için değil, bu
> hamle _illa ve illa_ yapılacaksa paketlere yama olarak eklenmeli.

Bu bir saçma sorun değil, gentoo da aynı şekilde çözmüş [0] ve gnome
bugzillasında açık hatası var. [1] Şu an daha düzgün bir çözüm
gözükmüyor ortalarda, daha kabul edilebilir bir çözüm bulabilirseniz
açığız tabiki.

(gnome2_omf_fix fonksiyonu)
[0]
http://mirrors.usc.edu/pub/linux/distributions/gentoo/eclass/gnome2-utils.eclass
[1] http://bugzilla.gnome.org/show_bug.cgi?id=407615

> > > GNOME'u da KDE gibi /usr/gnome altına mı koysak acaba?
> >
> > Düşünülebilir, ama ileride menüler ile ilgili sorun çıkabilir belki,
> > emin ve hazır değilim buna. Deneriz. Bu arada, get.gnomeDIR()
> > eklenmesi gerektiğini de unutmayalım :)
> 
> Ok, bu illa gerekli değil belki tam tersini yapıp KDE'yi sisteme
> yaymalıyız 2008 için, FHS/LSB öyle buyuruyor zaten.

OK

> > Yukarıda "olmaması gereken dosed/automake'i" açıkladım, o yöntem ile
> > sorunsuz görünüyor. Gnome.py'ye ihtiyacımız var çünkü bu az görülen
> > değişiklik *her* gnome paketinde tekrar edilecek,
> >
> > * dosed yaptığımız "scrollkeeper-update / echo"
> > --disable-scrollkeeper verdiğimizde bazen yine güncelleyebiliyor
> 
> Bu paket hatası ama pisi'nin ya da actionsAPI'nin problemi değil ki.
> 
> > * Her seferinde patch yapmak süreci uzatıyor.
> 
> Ne yazık ki paket hatalarını pakette çözmek gerekiyor, bu iş için
> paket yamalanacaksa yamalanmak zorunda.

Yukarıda açıkladım, Contrib'de bulunan en az 15 scrollkeeper kullanan
paketin ve ileride -olur ya- gelicek başka gnome paketlerinin
patchlenmesi beklenemez

> > * actions.py'nin build() kısımlarında shelltools ile değişken export
> > etmek kötü gözüküyor + amelelik oluyor
> 
> shelltools.export değişken export etmek kullanılıyor işini yapınca
> neden kötü görünsün, nasıl bir kozmetik kaygıdır bu :)

Kozmetik değil, ameleliğe takmıştım sadece. Yine bkz.: gentoo eclass.
(gnome2_src_install)

[0]
http://mirrors.usc.edu/pub/linux/distributions/gentoo/eclass/gnome2.eclass

> > * Build işleminden sonra icon-cache dosyası oluşmuş mu diye bakmak,
> > varsa remove kodu eklemek zorluyor.
> 
> Buna bir itirazım yok zaten

Güzel :)

> > * Tabiki bunların update işlemleri için comar betiğini eklemeyi
> > saymıyorum bile.
> 
> comar ile actionsAPI'nin ne alakası var? actionsAPI'de ne yaparak
> çomar'ı ekarte etmeyi başarıyoruz? pakhandler yazmak ile build
> işleminin alaksı yok ki.

Cümle düşüklüğü oldu orada, PackageHandler olmayınca eklenecek comar
betiğini kastetmiştim. Her pakette scrollkeeper patchi yapıp,
icon-cache'i silip, gconf'u düzelten adam zaten yeterince uğraşmıştır,
biraz daha kasıp comar betiğini de ekleyiversin değil mi? :) gnome.py
olmayınca PackageHandlerin bir anlamı kalmıyor bence..

> > Ufak değişiklikler ile tüm bunlardan kurtulmak iyi bir çözüm.
> > Paketçiye zaman kazandırıyor + uygulamaların kurulumlarında insan
> > faktörünü katmayıp hata payını en aza indiriyor.
> 
> Fakat actionsAPI'yi hackler ile dolduruyor, ben halen bunun gerekli
> olduğuna inanmıyor ve paket sorunları paketlerde çözülmeli diyorum
> malesef...

Diğer dağıtımların yaptığı gibi gereken değişkenleri export edip
scrollkeeper'i fixlemek, ileride gelen onlarca paketin önünü açmak hack
ise kalabilir tabiiki.

> Saygılar

Saygılar,
Eren



Gelistirici mesaj listesiyle ilgili daha fazla bilgi