[Gelistirici] component yapisi ve paket agaci taslagi

Fatih Aşıcı fatih at pardus.org.tr
7 Şub 2009 Cmt 20:33:19 EET


Cumartesi 07 Şubat 2009 tarihinde, Necmettin Begiter şunları yazmıştı: 
> 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? :)

Belki de bileşen listesini wiki'de bir yere yazıp onun üzerinden 
konuşabiliriz.

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

applications adında bir bileşen olmamalı bence. Bu sefer başka tutarsızlıklar 
çıkıyor. Mesela programming.ide altındakiler de application değil mi?

office bileşenini ana bileşen yaparsak hem KDE'deki menüye de benzetmiş oluruz 
biraz. KDE'de de aşağıdaki gibi bir hiyerarşi var:

graphics
multimedia
office
system
utility
	editors

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

interface çok genel bir kavram aslında. desktop.library bana daha uygun 
geliyor.

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

İçindeki x sürücüsü çıkıyor. Önceden X.org  çatısı altında değildi. O yüzden 
ayrı bir paket olarak duruyor 2008'de. Ama artık X.org ile gelecek.

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

+1

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

Belki de library bileşenlerindeki paketleri işlevlerine göre dağıtabiliriz. 
Dağıtmakta zorlandıklarımızı bir üst bileşene ya da misc adındaki bir bileşene 
atabiliriz.

misc/other bileşenleri olması istiyorsak şöyle bir yöntem izlenebilir. Eğer  
multimedia ile ilgisi olan bir paket alt bileşenlerden hiçbirine uymuyorsa 
doğrudan multimedia bileşeni altına alınabilir.

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

Bu server bileşeni bize zora sokuyor gibi geliyor bana. Çoğu uygulama ya 
client rolündedir ya da server.

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

langnames kısmından sonra ek alt bileşen yapmaya gerek de olmadığı için bir 
derinlik sorunu yok bence. Gayet düzenli böyle.

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

gfxtheme paketleri temadan fazlasını içeriyor. Sırf onun için theme bileşenini 
ana dala koymayalım bence.

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

Bence;

* Gerçekten yardımcı uygulamalar/kitaplıklar utility altında kalsın. Ek bir 
alt bileşene de gerek yok. Paket doğrudan utility bileşeni altında olabilir.
* office ana dala gelsin.
* utility.admin bileşeni system.admin, network.admin gibi bileşenlere 
dağılsın.

-------------- 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/09219d3e/attachment-0002.pgp>


Gelistirici mesaj listesiyle ilgili daha fazla bilgi