[Gelistirici] component yapisi ve paket agaci taslagi

[Necmettin Begiter]

On 06 Feb 2009 Fri 20:59:25 semen at pardus.org.tr wrote:
> Herkese selamlar,
> 
> 2009 icin hazirlamis oldugum yeni paket agaci taslagini
> http://svn.pardus.org.tr/uludag/trunk/component/ altinda bulabilir ve
> inceleyebilirsiniz. Bazi paketler icin kucuk aciklamalar dustum.
> 

Merhaba,

Yazacaklarım oldukça uzun, fekat tek tek her birinin ele alınmaya değer olduğunu düşünüyorum, iki saattir bilgisayar başındayım :)
(diğer bir deyişle, baktım ki kimse hepsini detaylıca incelemiyor, depoyu kısa bir süre için de olsa yukarıdan görme şansını elde eden kişi olarak kolları sıvadım).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- kdegames* (ve belki kdetoys) da aslında games altında olmalı.

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

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

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

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

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

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

- synaptics bir sürücü paketi olmasına rağmen desktop.freedesktop.misc altında.

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

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

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

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

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

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

- hplip-doc paketinin hardware.printing yerine documentation gibi bir bileşende olması gerekir.

- hardware.infrared altında ufak bir yazım hatası olmuş, son öğedeki lirc ayrı bir paket. Bir de lirc-drivers paketini göremedim orada?

- strigi hardware.disks değil. Donanımla ilgili birşey değil en azından. Bir indeksleme uygulaması (Google Desktop ve Beagle gibi).

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

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

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

- multimedia altında sound ve radio diye iki ayrı bileşen olması kafama takıldı.

- amarok-docs -> documentation

- cdparanoia (müzik cd'lerini okuma şeysi) gibi doğrudan donanım için olan paketleri hardware.discs altına taşımalı.

- streamtuner multimedia.radio altında ama streamripper multimedia.sound altında.

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

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

- streamtuner hem network.browser altında hem de multimedia.radio altında.

- network.mail mi, network.email mi?

- metalink epostalarla ilgili bir paket değil; aynı kaynağa birden fazla adres verilmebilmesini sağlıyor.

- checkgmail bir süzgeç değil, kniff de bir istemci değil. İkisi de "you have new mail" diyor..

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

- network.client altındaki diğer paketler de istemci değil birer uygulama, aynı network.transferring altındakiler (pilot-link hariç) gibi.

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

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

- www server yerine web server daha anlamlı geliyor (server.web).

- 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.ftp altındaki kftpgrabber, ncftp, gftk ve netkit-ftp, sunucu değil, istemci.

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

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

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

- ntp-client bir server.ntp değil, bir istemci.

- memcached, benim bildiğim, bir sunucu değil, bir tür ara yazılım (ayrıca pisi info memcached -f niye hiçbirşey döndürmüyor?)

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

- programming.environment -> programming.ide

- programming.putyourfavouritelanguagenamehere ile programming altında ayrı bir ağaç yaratıyoruz.

- programming.cpp.library (programming.)library altına taşınmalı. 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 :)

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

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

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

- kernel.drivers.cameras yerine kernel.drivers.webcam öneriyorum.

- kernel.drivers.pcmcia-cards yerine de kernel.drivers.pcmcia öneriyorum.

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

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

- gfxtheme-pardus-* utility.admin değil, tema.

- network-manager utility.admin altına taşınabilir (yukarıdaki önermemi kabul etmeyenler için;)

- gvim niye utility.editors.emacs altında :)

- *zemberek*'ın utility.dictionary.library / utility.dictionary.spellchecker altında olması gerekir.

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


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)
-- 
Necmettin Begiter