component'larla ilgili notlar

1. Temel feature'lar (Eray)
--------------------

Iki yerde component tag'i tanimladik simdiye kadar, bir
source'larda bir de binary'lerde. Binary'de tanimlanan component default
olarak source'daki tanimi inherit ediyor ve tanimlanan component'i override
edebiliyor.

Bir component temel olarak bir meta-package, icerisinde paketler olan
bir paket. Bir component'in icerisinde bir takim source'lar ve bir takim
binary'ler bulunuyor diye bakabiliriz. Sanirim query'leri bu sekilde yapmak
mumkun olmali.

$ inary list-components
$ inary info system.base
  Source packages in system.base:
    ....
    ....
  Binary packages in system.base:
    ....
    ....

gibi ozellikler eklemeyi umit ediyorum.

Source'larin component tag'leri de, gene sadece bir senaryo konusuyorum,
direkt olarak directory structure'indan inherit alinacak. Ayni zamanda o pspec
icin de bir tane component tanimlananack default olarak, ve bu component o
scope'da tanimlanmis olan butun binary package'lari icerecek.

Ornegin diyelim ki a/b/c/pspec.xml var ve c1 c2 c3 seklinde uc tane paket
tanimliyor. Hic bir component tanimi yapilmadigi zaman otomatik olarak bir
a.b.c component'i olusturulacak, ve bu component'in icerisinde c1 c2 c3
bulunacak.

$ inary info a.b.c
  Source packages:
    c  - oldur beni yarim sen olmazsan biterim
  Binary packages:
    c1 - bu aksam demlenmemek sonum olur benim
    c2 - sincaplarla konustum butun gece
    c3 - her gul gordugumde icim kan aglar

Bu varsayilan davranis, ama  bunu degistirmek mumkun olacak. Burada yamuk
gozukebilecek bir sey var, o da tek bir paket oldugunda sanki biraz
redundancy olmasi, o takdirde bir optimizasyon olarak, diyelim ki
a/b/c/pspec.xml'in icerisinde tek bir paket tanimli c1

$ inary info a.b
   ....
   c1 - dil dil dillerdeyim

olabilir bu durumda, bu genel agac mantiginda bir sorun yaratmayacaktir.


2. Temel tanım (Barış)

fiziksel aitlik: kdebase'den çıkan kcontrol gibi; grup aitliği: pdf
göstericileri gibi...


3. Database XML ayrımı (Barış)

Component database'i ile component.xml ayrı olmalı. Component database,
inary'nin inary-index.xml dosyasını okuyarak oluşturacağı bir veritabanı. Hangi
paketler hangi componentlere dahil, vs. sorguları bu veritabanından
yapılacak.

Pspec dosyasını hatırlayalım. İçerisinde bir <PartOf> diye bir tag var.
Oluşturulacak paketin hangi component'e ait olduğunu belirtiyor. Bu bilgi
inary-index.xml dosyasına da koyulmalı.

4. PL modüllerine benzerlik (Eray)

component tag'leri Java ya da python'daki gibi
directory yainaryndan cikiyor. Yani inary bir programlama dili olsaydi
component'lar module'ler ya da package'larla es anlamli olacakti.

5. Mereology ve Eray'ın açıklama çabaları (Eray)

PartOf iliskisi hakkında su kadarini soylemek yeter: eger a b'nin bir parcasiysa,
a'nin fonksiyonu b'nin fonksiyonunun bir parcasidir. Bu da fiziksel sistemler
icin bir principle of compositionality'nin varligindan hareket eder [*]

Genel olarak da software engineering ve AI camiasinda module'un tanimi gayet
iyi bilinir. Bir modul icerisindeki bagimliliklar yogundur. Moduller arasindaki
bagimliliklar zayiftir.

Bu tanim sadece software engineering'de degil, nesneler arasindaki
benzerliklerin incelendigi bir cok disiplinde kullanilan informal bir tanim,
ama tabii ki formule dokulmus bir ton hali var.Sırf bu tanımı taban alarak
yazılmış başarılı kümeleme (clustering) algoritmaları var.

Modulerlik tanimi verilen *fiziksel* modul ve parcasi olma iliskisiyle
birlesince birlikte install edilip remove edilme yahut ortak bağımlılıklara
sahip olma tanımlarına götürür.

Bu tanımı analiz edebilmek için parcasi olma iliskisininin anlamini
korumamiz yeterli. Temel olarak

  kol insanin parcasidir

iliskisi burada yer aliyor.  Eger

  a partof b

turu iliskilerde a paket ya da component, ve b component ise, a ve b'nin
iliskisinin kol ve insan iliskisi gibi olmasini bekleriz. Eger bu parca-butun
iliskisini ihlal ediyorsa o zaman muhtemelen yanlis bir iliski bulunmus
demektir.

Bunun turlu sonuclari da onem sirasina gore soyle dizilebilir:

1. Fonksiyonlarin bolunebilmesi prensibinden: (basit bir sonuç)
   a's function is part-of b's function

   orneğin kolun fonksiyonu insanın total fonksiyonunun bir parçasıdır.

paket ornegi: inary'nin fonksiyonu olan paket yükleme/çıkarma system.base'in fonksiyonunun, yani temel pardus sisteminin fonksiyonunun bir parçasıdır.

2. Karmasik sistemlerde birbirine dayanan ufak parcalarin kararli yapilar
meydana getirmesi prensibinden: (evrimsel sonuç)

   if a is a part-of c, and b is a part-of c, then it follows that a and b
may:
     a. have many interdependencies
     b. share in their origins
  (which are about the same thing)

2b. sonucunun bizim durumumuza uygulanması, source code'un aynı kaynaktan
çıkması, birlikte inşa edilmeleri gibi şartları getirir. Bunun oldukça
olasi, en azindan insa metodlarinin ve kaynaklarının birbirine benzemesini
bekleriz. Yalniz, 2.a'daki bagimliliklar sadece insa ile degil ayni zamanda
calisma ile de alakalidir. Kaynakları farklı parçaların birbirine bağımlı
hale gelebilecegini unutmamak gerekir.

Fedora'nin yaklasiminin hos tarafi, boyle teknik ayrintilara girmeden "package
group" mantigini kullanmasiydi, ama bizim belli bir anlami olan parca-butun
iliskisini korumamiz daha mantikli bir yazilim ontology'si ortaya
cikaracaktir. Onlarin yaklasimi ise "anything goes", grup ile kategori'nin
temel bir farki yok cunku, herhangi bir bakis acisi olabilir "grup".


6. Modulleri test etmek (!!) (Eray)
------------------------------------

INARY'deki seçilen implementation detaylari bir tanima cok fazla commitment
yapmiyor, implementation'ın getirdiği tek şey paketleri bir ağaca koymak.
Component'ların seçiminin ne kadar kaliteli olduğunu belirleyemiyor.
Paketlerin ve componentlarin secimi yapiyor, ki kritik olan o.
Yalnız modulerlik tanimindan ve part-of iliskisinin
  if a is part of b, and b is part of c, then a is part of c.
  if a is part of b, and b is not part of c, then a is not part of c.
gibi sonuclari getirmesinden hareketle (ki bunlar klasik computational
ontology) kismen test edebilecegimiz bir sekil aliyor ornegin bagimlilik
graph'ini cluster ederek, ya da her modul icin bir modulerlik sayisi
hesaplayarak. Daha az formal olarak da bu sonuçları kafamızda yürüterek
yaptığımız componentların ne kadar akla yatkın olduğunu bulabiliriz.


7. Cagların frugalware önerisi
------------------------------

http://ftp.frugalware.org/pub/frugalware/frugalware-current/source/
adresindeki yerleşimin hem source hem de binary depo için uygulanmasını ve
kategori, componentların da bundan çıkartılmasını öneriyorum.
