Change to project/trunk,tags,branches style
This commit is contained in:
Faik Uygur
@@ -0,0 +1,167 @@
|
||||
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.
|
||||
|
||||
$ pisi list-components
|
||||
$ pisi 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.
|
||||
|
||||
$ pisi 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
|
||||
|
||||
$ pisi 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,
|
||||
pisi'nin pisi-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
|
||||
pisi-index.xml dosyasına da koyulmalı.
|
||||
|
||||
4. PL modüllerine benzerlik (Eray)
|
||||
|
||||
component tag'leri Java ya da python'daki gibi
|
||||
directory yapisindan cikiyor. Yani pisi 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: pisi'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)
|
||||
------------------------------------
|
||||
|
||||
PISI'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.
|
||||
Reference in New Issue
Block a user