preliminary notes
This commit is contained in:
@@ -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