[Gelistirici] component yapisi ve paket agaci taslagi

[Fatih Aşıcı]

Öncelikle eline sağlık :) Uğraşıp güzel bir inceleme yaptığın için. Çok 
faydalı oldu.

Cumartesi 07 Şubat 2009 tarihinde, Necmettin Begiter şunları yazmıştı: 
> Bir de şunu söyleyeyim, depoda birbiriyle ilgili paketlerin birbirine yakın
> durmasının geliştirici açısından kolaylık sağladığı görüşü söylenmişti daha
> önce, burada da bahsi geçen birkaç önermem sonucunda. Eğer o görüş
> geçerliliğini koruyorsa, o library bileşenleri kökten kaldırmak lazım
> bence. Yok korumuyorsa, o zaman library'leri o kadar aşağılara çekmemeli,
> kökün hemen altına koymalı.

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.

> - Öncelikle, documentation diye bir bileşen olmalı, tamam, ama
> belgelendirme ile ilgisi olmayan, daha çok belge düzenleme vb işler için
> uygulamaları, kütüphaneleri vb içeren bir bileşen olmamalı.

+1

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

> - desktop.gnome.library altında libglade2 ve libglademm kardeşleri ve
> cairo'yu görüyoruz fakat cairo'nun kardeşi cairomm desktop.gnome.extras
> altında; cairomm'in yeri cairo'nun yanıdır.

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.

> - gtk2-docs desktop.gnome.base altında duruyor. Bu bir belgelendirme
> paketi, taban paketlerin arasında olmamalı.
>
> - gtk2-demo, GTK+2 için örnek kaynak kodların yer aldığı bir paket (değil
> mi?); dekstop.gnome.base altında olmamalı. documentation çok daha anlamlı
> bence bu paket için.

Bunları yeri documentation olur bence de.

> - QtCurve-Gtk2, bir cilt/tema/adınısizkoyun paketi. Paketleri işlevlerine
> göre yerleştiriyorsak, desktop.gnome.extras altında olmamalı. Zira GTK2
> başka şey, GNOME başka şey, Qt başka şey, KDE başka şey. Kök noktaya
> eklenen bir skins bana hoş bir isim olur gibi geliyor, duvar kâğıtları,
> pencere şeyleri, grafik atraksiyonları, fare temaları ve diğer bilimum
> (bilumum da olabilir) paket için.

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

> - Ya extras ve libraries olmalı, ya da extra ve library.

+1

> - i18n desktop'un dışına (ana dala) taşınabilir.

+1

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

> - kdelib-apidox, KDE kütüphanelerinin kullanımını belgelendiren bir paket.
> documentation bu paket için çok daha anlamlı bence. Değilse bile,
> kdelibs-apidox bir desktop.kde.library değil. (Bir de niye apidox, apidocs
> değil?)

Bu paketi uçurdu Gökçen :) Olsaydı yeri documentation tabi ki.

> - PolicyKit-kde PolicyKit ile KDE arasındaki boşluğu dolduran bir paket
> ise, desktop.kde.extras doğru yer değil, desktop.kde.library olabilir.

KDE4'de ilerde birlikte gelecek sanırım. O yüzden +1.

> - basket bir ofis uygulaması, desktop.kde.extras değil utility.office
> içinde olmalı. (Öte yandan utility deyince benim aklıma küçük uygulamalar
> geliyor, openoffice gibi uygulamalar değil.)

+1 (+1)

> - artwork-pardus-release, QtCurve*, desktop.kde.base.artwork paketlerinin,
> eğer işlevlerine bakarak yerleştiriyorsak, ayrı bileşenlerde olması anlamlı
> değil. cilt/tema/x bileşenine taşınmalılar.

Yukarda söylediğim desktop.theme bileşenine girmeli bunlar da.

> - PyKDE ve PyKDEeXtensions KDE'nin kendi temel zorunlu bileşenlerinden
> değil, bizim KDE için yazdığımız uygulamalar nedeniyle temel paketlerden
> olmuşlar. Kütüphaneler arasına taşınmalı.

KDE4'te artık öyle değil. Paketi ayırırsak python modüllerinin yanına 
koymalıyız bence.

> - kdeartwork* olmadan da KDE gayet güzel çalışıyor, bu paketler de tema
> altına taşınmalı.

+1
Bu paket parçalanabilir de aslında. 

> - kdebase-beagle'ın desktop.kde.base altında olmaması gerekir, Beagle Mono
> ile yazılmış bir uygulama, kdebase-beagle da Beagle ile KDE'nin
> anlaşabilmesi için var; belki desktop.kde.extra olabilir yeri.

Bu olmayacak zaten ilerde.

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

> - İlgisiz bir soru, niye tulliana ve tulliana2 diye iki paket var?
> Tulliana2'nin açıklamasında "Tulliana2 is the default icon theme of  Pardus
> Linux 2007" yazıyor, tulliana2 release 4 build 2, tulliana ise release 1
> build 1. Tulliana fazla mı, unutulmuş mu nedir?

Unutulan birşey olduğu kesin :)

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

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

graphics olabilir belki?

> - freedesktop.fonts altında sadece uygulamalar var, fontforge ve gbdfed
> buraya taşınmalı ya da bunlar fontforge ve gbdfed ile aynı yere taşınmalı.

fontconfig bir library. Diğerleri sadece X tarafından kullanılıyor. 
Kullanıcının kullanacağı şeyler değil. freedesktop bileşeni olmamalı. Yerine 
desktop.library kullanılmalı. Xorg için system.x11 düşünüyorum.

> - xorg-doc Xorg belgelendirmesi olduğuna göre ilgili yere gitmeli.

+1

> - xcursor-themes freedesktop.xorg.theme altında iken grounation-xcursors ve
> jimmac-xcursor freedesktop.misc altında. (Ayrıca biri xcursor iken diğer
> xcursors?)

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

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

> - GUI kütüphaneleri ayrı bir sınıfta olmalı. Qt ve GTK'nın dağınık olması
> bir yana, örneğin wxGTK desktop.freedesktop.library altında duruyor.

desktop.library benim görüşüm.

> - Belgelendirme paketleri ayrı bir yere taşınmalı, game.library içinde
> clanlib-docs, ogre-doc, cel-doc gibi paketler var. Bunlar kütüphane değil.

+1

> - rougelike diye bir oyun türü yok. O bildiğin RPG.
>
> - game.simulation altındaki lincity, opencity ve simutrans strateji oyunu,
> benzetim değil. (Şehir kurma ya da trenle taşımacılık şirketi üzerinden
> dünyayı ele geçirme oyunları benzetim oyunları değildir :p)
>
> - games.strategy altındaki freegiv'in doğrusu freeciv :)

Pek bilgim yok :/

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

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

Bunu bilemedim.

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

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

> - hal-doc hardare.misc'den documentation'a taşınmalı.

+1

> - Çoklu ortam kütüphanelerini (multimedia.library) audio, video, graphics
> diye ayırmak anlamlı olabilir (?)

.library bileşenlerini ayırmaya gerek yok bence.

> - multimedia.graphics altındaki graphviz-docs ve tuxpaint-doc
> documentation'a taşınmalı. (doc-docs konusunda da bir eşgüdüm sağlanmalı,
> ya doc, ya docs ya da dox olmalı -do* olan paketler)

+2

> - amarok-docs -> documentation

+1

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

Bence uygun görünüyor.

> - network.browser altındaki firefox*, lynx, opera, arora network.webbrowser
> olsa mesela..

Olabilir.

> - network.client altındaki wpa_supplicant bir kütüphane, network.library'ye
> çekilmeli.

Bundan emin değilim. wpa_supplicant uygulama sayılabilir. Hatta içinden wpa-
cli ve wpa-gui çıkıyor bildiğim kadarıyla.

> - network.client altındaki network-manager network.connection altına
> taşınabilir

administration bileşenine mi alsak acaba bunu?

> - Öte yandan network.connection altındakiler de birer uygulama,
> network.client'ları (wpa_supplicant hariç) ve network.connection'ları
> network.applications yapmak daha anlamlı geliyor.

applications ismini hiç kullanmayalım bence.

> - mod_dav_svn de bir apache modülü, apache için yeni bir bileşen açmak
> gerekliyse mod_dav_svn de diğer mod*'larla birlikte olmalı. Ya da bunun
> yerine mod*'ları server.web'e çekmeli.

server'ın olduğu bileşene çekilmeli.

> - server.ftp altındaki kftpgrabber, ncftp, gftk ve netkit-ftp, sunucu
> değil, istemci.

+1

network altında ilgili yerlere gitmeleri gerekiyor.

> - avahi bir server.dns uygulaması değil, paket açıklamasına bakılırsa
> servis keşif uygulaması. Aynı zamanda da ağda yerel bilgisayar tarafından
> sunulan servisleri yayınlıyor, fakat server.dns değil.

Doğrudan network altına da konabilir belki.

> - bind-tools da bir server.dns değil, sorgu uygulamaları içeriyor.

+1

> - openldap-client server.authentication uygulaması değil, bir istemci.
>
> - ntp-client bir server.ntp değil, bir istemci.

+1

> - programming.library bana hiçbir zaman anlamlı gelmedi. Programlama
> kütüphanesi dediğimiz şey, düz kütüphane değil midir?

Bunları olabildiğince diğer bileşenlere dağıtmamız lazım. Eğer bileşen 
bulamıyorsak. utility.library gibi bir bileşene gidebilir.

> - programming.environment -> programming.ide

+1

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

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

> - Söylenmiş ama, erlang ve nasm'nin embedded içinde olmaması gerekir.
> Mevcut düzene uyulacaksa programming içinde olması gerekir.

Ya programming ya da programming.language.

> - Ana bileşenlerin bazılarının altında library bileşeni olması bana hiç
> anlamlı gelmiyor. Örneğin gmm, bir C++ şablon (template) kütüphanesi, onun
> science altında ne işi var diye düşünüyorum. Bir bilim uygulaması
> tarafından kullanılıyor, tamam, ama bu onu bir bilim kütüphanesi yapmıyor.
> Mesele geliştiricinin ilgili paketlere kolay erişmesi için o ilgili
> paketleri birbirine yakın yere koymaksa, gmm büyük ihtimalle sadece x
> uygulaması tarafından kullanılıyordur, onu o uygulamayla aynı yere koymak
> lazım. Yok birden fazla uygulama tarafından kullanılıyorsa, herhangi bir
> kütüphanenin bir bilim kütüphanesi olduğuna nasıl karar verilir? Diğer
> bileşenlerdeki paketlerin herhangi biri tarafından da kullanılıyorsa ne
> yapılacak?

gmm bilimsel amaçlı bir kütüphane. Yeri doğru bence.

> - hesap makinesi uygulamalarının (örneğin qalculate) science.mathematics
> altına konması anlamlı gelmiyor. Uygulamayı kurmadım, ne kadar derin
> bilimsel hesaplar yapabiliyor bilmiyorum ama multi-purpose desktop
> calculator dediğine göre çok da derin değildir sanırım ;)

Yok aslında basit bir hesap makinesi değil bildiğim kadarıyla.

> - antiword, kchmviewer, bookreader, tidy gibi uygulamaların documentation
> altında olmaması gerekir. Aslında documentation altındaki paketlerin büyük
> çoğunluğunun (-do* diye bitenler hariç) documentation ile ilgisi yok.

+1

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

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

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

> library
> 	bir derleyici ya da yorumlayıcının kurulu olmasını gerektirmeyen (bir dile
> bağımlı olmayan tüm kütüphaneler) programming
> 	compilers
> 		gcc, gfortran vb
> 	interpreters
> 		python, perl, php vb
> 	ides
> 		eric, idle vb
> 	template enginleri
> 		smarty vb
> 	modules
> 		python*, perl*, django* tüm modüller buraya (isterseniz burayı dillere
> göre ayırırsınız, ama bence gerekli değil)

Hmm. Bu da fena değil. Olabilir bence.

-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090207/40b254cb/attachment-0002.pgp>