[Gelistirici] Gnome ActionAPI

[S.Çağlar Onur]

01 Tem 2007 Paz tarihinde, Eren Türkay şunları yazmıştı: 
> 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.

ÇÖZÜM = Bozuk paketleri düzeltmek. actionsAPI _paket sorunlarını_ çözmek için 
değil farklı build sistemlerini modellemek için var ve bu işlerin hiç biri 
bir cmake/autotools veya perl gibi bir model değil.

> 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

15 değil 155 paket de olsa _doğru olan_ çözüm = Bozuk olan paketleri düzeltmek

> > > * 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)

Gentoo'nun da eclassların da ne yaptığını nasıl yaptığını/neyi doğru/neyi 
yanlış yaptıklarını gayet iyi biliyorum.

> > > * 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..

...

> 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.

...

Tartışmayı farklı ve gergin bir yere çekiyorsun. Ne pakHandler'ın actionsAPI 
ile alakası var ne de bu paketlerde yapılan iş binlerce satır.

Ben atıyorum GCC/glibc paketine 5 satır az yazacağım diye;

if packageName == "gcc":
   # create needed symlinks
   pisitools.dosym(...)
elif packageName == "glibc":
   # create hede höd
   pisitools.insinto(...)

gibi acayipliklerle actionsAPI'yi doldurmak ile hiçbir teknik farkı olmayan 
birşey bu önerdiklerin.

Bu tarif ettiğin sorunlar ne PiSi'nin ne de actionsAPI'nin 
sorunları/yetersizlikleri, GNOME paketlerinin upstream'den bozuk çıkıyor 
olması problemini çözmek _paket yöneticisinin_ işi değil bir kere, bu 
sorumluluk upstream'in veya paketleyenin, upstream veya paketleyen bu 
sorunları çözmüyorsa;

a) Bu paketlerdeki bu sorunlar çözülene kadar bu paketler depoya girmez,
b) Bu sorunları çözmek isteyen biri bu paketlerin sorumluluğunu alır.

ve bu yazdıklarımın GNOME ile uzaktan yakından da alaksı yok, aynı işi KDE de 
yapıyor olsaydı aynı direnci göstermeye devam edecektim.

-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20070701/20d5d0f7/attachment-0002.pgp>