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