[Gelistirici] component yapisi ve paket agaci taslagi

[Necmettin Begiter]

On 07 Feb 2009 Sat 03:20:08 Fatih Aşıcı wrote:
> Öncelikle eline sağlık :) Uğraşıp güzel bir inceleme yaptığın için. Çok 
> faydalı oldu.

Bu saydıklarımızdan uygun görülenleri kim uygulayacak? :)

> Bence geliştiriciye hiç acımayalım :) Bileşenler tamamen grafik arayüzde nasıl 
> görüneceği dikkate alınarak, kullanıcının bakış açısı düşünülerek 
> belirlenmeli.

Yerinde bir görüş, katılıyorum.

> Önceki mailimde belirttiğim gibi taslakta yer alan hali office, publishing 
> gibi üst bileşenlere dağıtılmalı.

desktops.
applications.
libraries.
ve diğer ana dallar (system,..)

gibi bir yaklaşım nasıl olur?

> Bunlar artık GNOME'a özgü değil anladığım kadarıyla. desktop.gnome altında 
> sadece gnome paketleri olsun. gtk, qt, vs hepsi desktop.library gibi bir 
> bileşene gitmeli.

Qt, GTK vd aslında grafik arayüz kütüphanesi olduğuna göre, misal, yukarıda verdiğim libraries. altına interface. diye bir bileşen nasıl olur?

> 
> Bu da desktop.theme bileşenine gitmeli. Hatta bu bileşen altında
>   /style
>   /icon
>   /decorator
> 
> gibi alt bileşenler olabilir. gtk veya qt teması olmasına hiç bakmıyoruz. 
> QtCurve-gtk2 ile lipstik aynı bileşende olabilirler. İkisinin de işlevi aynı.

+1

> l10n veya locale de olabilir. Hangisi daha kapsamlıysa onu seçelim bence.

i18n uluslararasılaştırma (ingilizce'den diğer dillere çeviri), l10n sayılarda . yerine , kullanmayı ifade ediyor. locale ise, hepimizin bildiği üzere, "yerel" anlamına geliyor, bir uygulamanın -hangi dile olursa olsun- geçişini sağlayan tüm paketler locale bileşeninde olabilir mesela.

> > - kdegames* (ve belki kdetoys) da aslında games altında olmalı.
> 
> Evet, olabilir. Şöyle de olabilir: Source paket desktop.kde altındayken 
> içinden çıkanları (oyunları ayrı paket yaparsak diye söylüyorum) games altına 
> alabiliriz.

Burada da şöyle bir ilginçlik var ki, kdegames* paket yöneticisinde KDE altında görünüyor. Yani bir bilgisayardan kurulumda gelen kdegames'i kaldırdıysanız, oyunların arasında değil, KDE bileşeninde görünüyor. Bu bana hep garip gelmiştir. Bir kullanıcı olarak düşündüğümde daha da garip geliyor :)

> > - Milky bir simge seti değil mi? desktop.kde.themes içinde ne işi var (ya
> > da diğer durumda tulliana* niye desktop.kde.base içinde)?
> 
> Bunu sadece KDE değil diğer ortamlar da kullanabilir zaten. 
> desktop.theme[.icon[set]]

+1

> 
> > - Font uygulamaları (fontforge, gbdfed) desktop.fonts altından çıkarılmalı.
> 
> graphics olabilir belki?

Yukarıdaki önermemden devam ediyorum. applications.publishing ?

> freedesktop bileşeni olmamalı. Yerine 
> desktop.library kullanılmalı. Xorg için system.x11 düşünüyorum.

+1. +1. +1

> İsimlerde standartlaşmaya gitmemiz lazım aslında. hede-cursor-theme gibi. 
> Bunların yeri de desktop.theme[.cursor]

+1

> 
> > - synaptics bir sürücü paketi olmasına rağmen desktop.freedesktop.misc
> > altında.
> 
> Bu diğer x sürücülerinin yanına gidecek. system.x11.driver gibi.

synaptics bir X sürücü paketi değil bildiğim kadarıyla?

> > - hardware altındaki cdr'yi gördüğümde ne olduğunu paketleri görünceye
> > kadar anlamadım. storage veya discs olabilir adı (diğer dağıtımlarda cdr
> > diye bir bileşen var mı?).
> 
> +1. Daha açık olmalı burası. Bazı dağıtımlar Archiving içine alıyor.

hardware.disks var, bir de hardware.cdr var, bir de DVD paketleri var. Bunları hardware.storage altına alsak?

> > - sane-backends tarayıcılarla (scanner) ilgili bir paket, hardware.graphics
> > altında olması bir an düşündürdü.
> 
> Bunu bilemedim.

Tekrar düşününce, hardware.graphics iyiymiş :)

> 
> > - hardware.mobile altındaki libopensync telefon ya da PDA'lara özel bir
> > kütüphane değil. Paket isimlerinden de görebileceğiniz gibi, PIM
> > uygulamanızın LDAP ya Google Calendar gibi sistemlerle çalışabilmesi
> > içinler. Dolayısıyla hardware.library altına taşınmalı. Aynı şekilde,
> > obexftp ve wbxml2 de birer kütüphane.
> 
> Dediğin gibiyse +1 tabi ki.

İçlerinden komut satırı uygulamaları çıkıyor, fekat asıl işleri programlara API ve veri sağlamak olduğundan böyle bir teklif getirdim. Ama kütüphaneleri 10 ayrı yere bölmenin kolaylaştırıcı değil zorlaştırıcı bir yaklaşım olduğu görüşümün arkasındayım.

> 
> > - hplip-doc paketinin hardware.printing yerine documentation gibi bir
> > bileşende olması gerekir.
> 
> +1
> 
> > - strigi hardware.disks değil. Donanımla ilgili birşey değil en azından.
> > Bir indeksleme uygulaması (Google Desktop ve Beagle gibi).
> 
> Bunlar için desktop.[misc,extra,accessory,tool] düşünülebilir.

desktop.indexing diyeceğim ama 2009 ile birlikte Beagle uçacağına ve Strigi ile işimizi halledeceğimize göre desktop.tool uygun olur bence.

Herhangi bir bileşene extra adını vermek de "bunları nereye koyacağımızı bilemedik, kaldı öyle" demekle eşdeğer gibi geliyor :)

> > - multimedia.sound altındaki sunucuların (jack-audio-connection-kit,
> > pulseaudio*, timidity) yerlerinin orası olduğundan şüpheliyim.
> 
> Bence uygun görünüyor.

Bir server.multimedia olabilir belki?

> > - programming.putyourfavouritelanguagenamehere ile programming altında ayrı
> > bir ağaç yaratıyoruz.
> 
> Doğru. Bunları da ayırabiliriz. Ancak bileşen derinliği gittikçe artıyor :)
> O yüzden bu dil bileşenlerinin altında da alt bileşenler yapmasak iyi olur.

İlgili paketleri programming.languages.langnames altına toplamak fazla mı derin olur? (Derin olsa da gayet düzenli olur diye düşünüyorum.)

> 
> > - programming.cpp.library (programming.)library altına taşınmalı.
> 
> Genel amaçlı c++ kitaplıkları için programming.language.cpp yeter bence. 
> Ayrıca bir de library bileşenine gerek yok.
> 
> > programming.qt programming.library altına taşınmalı (ya da isterseniz,
> > jargona uyar, programming.toolkit deriz). iki farklı tasnifi tek bileşen
> > altına koymak (programming.diladı, programming.environment/library vb)
> > arama süreçlerini zorlaştırıyor. her dile yönelik kütüphaneleri ayrı
> > kütüphanelere koymak da tam bir kullanılabilirlik kabusuna neden oluyor. Bu
> > programming için başka türlü bir önerim var, aşağıda, inceleyiniz.
> >
> > - PyQt* niye programming.python altında? programming.python.libs olsun en
> > azından. Programming'in altı insanın kabuslarına girecek kadar karışık
> > görünüyor :)
> 
> python modüllerini python bileşenine almamızda bir sorun yok bence. Dilleri 
> içine alan bir language bileşeni yaptığımızda karışıklık yeterince 
> giderilmeyecek mi?

Evet, programming.language[s?].langnames__iter orayı hizaya sokar. :)

> > - hesap makinesi uygulamalarının (örneğin qalculate) science.mathematics
> > altına konması anlamlı gelmiyor. Uygulamayı kurmadım, ne kadar derin
> 
> Yok aslında basit bir hesap makinesi değil bildiğim kadarıyla.

Benim derdim, kısacası, hesap makinelerini scientific altına almamak..

> > - her yerden kütüphane fışkırıyor :) Bir de utility.archive altında,
> > utility.crypt altında, utility.dictionary altında varmış. Bun kütüphaneleri
> > bir araya toplamak şart.
> 
> Aslında ayrı da olabilirler; ama küçük bileşenler olduğu için dediğin gibi 
> olabilir.
> 
> > - gfxtheme-pardus-* utility.admin değil, tema.
> 
> desktop.theme diyeceğim; ama masaüstü ile ilgili değil aslında. Kullanıcıya 
> burada tema seçem lüksü de vermiyoruz sanırım. O yüzden kullanıcıya 
> göstermesek iyi olabilir.

İleride depomuzda başka temalar da olabilir. O yüzden desktop.theme güzel. Hattâ temaları, fare derilerini (bunu çevirmese miydim ne) oturum açma ekranlarını fakat bir ana bileşen altına toplamak oldukça çekici bir düşünce :)

> 
> > - *zemberek*'ın utility.dictionary.library /
> > utility.dictionary.spellchecker altında olması gerekir.
> 
> +1. Ancak bu utility altındakilerin ana bileşen olmasınu ciddi ciddi düşünmeye 
> başladım.

Ben applications.'ı o yüzden önerdim zaten. O utility'lerin yarıdan fazlası utility değil, application (veya koca koca ara katman uygulamalar, kütüphaneler vb). *zemberek* için söylemiyorum ama köke bir applications. şart.

> 
> > - Paket yöneticisinde arama yapacak kişiyle SVN depoda bileşenlerin içinde
> > bir paketi bulmaya çalışan kullanıcıyı çok da farklı düşünmemek lazım.
> > -docs, -doc ve -dox'ların hangisinin nerede olduğu belli değil (kendi adıma
> > konuşayım, ister depo olsun ister paket, kde-docs diye bir paket olsaydı,
> > ben onu desktop.kde.base altında aramazdım, doğrudan documentation
> > bileşenine bakardım. Depoda bir kütüphane arıyorsam ve aradığım
> > kütüphanenin de hangi tür işlerde kullanıldığını çok iyi bilmiyorsam (veya
> > örneğin çok amaçlı bir kütüphane olsun) bulana kadar depodan ümidimi
> > keserdim. (Yeri gelmişken, -i18n* paketleri nasıl oluyor da paket
> > yöneticisinde uygulama olarak kabul ediliyor, bunu kimse fark etmedi mi
> > yahu?)
> 
> Ben script kullanıyorum. Hiç aramıyorum paketleri. svn tarafında arama işi o 
> kadar önemli değil bence.

SVN tarafında arama işi düzene alışmış geliştirici açısından önemli değil, evet, zaten bir süre sonra insan neyin nerede olduğunu ezberliyor, ama ben geliştiricinin, yeni geliştirici adayının ve kullanıcının işini (en azından depodaki paketlerin düzeni babında) ne kadar doğallaştırır ve kolaylaştırırsak o kadar iyi olur diye düşünüyorum.

-- 
Necmettin Begiter