> `/usr/share/belgeler' dogru olmaz kanaatimce. (Sadece dokumantasyon'dan > ibaret olup /usr/share/paket altina kurulan bir paket'e su ana kadar > rastlamadim.) Ben derimki bu paketi all-in-one yapmayalim. Eger bu > konudaki dusuncemi uygun bulursaniz onerilerim sunlar olacak:
Aslinda salt dokumantasyondan olusan paketler icin dizin yapimiz belli: /usr/share/doc/belgeler ve alt dizinleri seklinde. Burada biraz dusunulecek nokta ileride salt dokuman haricinde bir takim binary ve scriptler de paketlenirse Debian Policy 13.3'teki durum meydana gelir. Orada /usr/share/paket_adi/doc seklinde bir linkin /usr/share/doc/... altindaki dokumanlarin bulundugu yeri gostermesi soyleniyor. Bir kac paket /usr/share altina dogrudan sadece dokumantasyon yerlestirmis ama biz share/doc olarak gidersek daha dogru olacak. Bir kaç pakete bölmek kaçinilmaz gözüküyor. Bu durumda HOWTO ve FAQ için ayri paketler yapmak gereksiz. Bu isin biraz ortasini bulmaliyiz, maksimum hiyerarsik duzene degil, duzeni bozmadan optimum çözüme dogru gitmeliyiz. Çünkü Debian'daki paket sayisi oldukca fazla, ve su anda her bir paketle ilgili bilgilerin yarattigi ek yük (Descriptions, Depends vb alanlari) nedeniyle apt-get update islemleri uzun sürüyor, bu paket descriptionlarini kucultmek icin calismalar yurutuluyor. Belgeleri en ust seviyede 5-6 basliga ayirabilirsek bunlar icin birer paket yapabiliriz. belgeler-all gibi bir paket bence olmasa da olur. Bunun yerine belgeler-common gerekli dizinleri ayarlar. belgeler-nasil HOWTO ve FAQ içerip belgeler-common paketine baðýmlý olur. belgeler paketi ise tüm belgeleri içeren bir meta paket olabilir. Beej guide ve python kilavuzu gibi belgeler için aslinda ayri paket yapilmasi en dogru olani. Ama bu yola girersek ileride paket sayimiz cok artabilir. Paketlere isim vermek epey zor olacak gibi. belgeler-common yerine belgeler-ortak demek cogu bakis acisina gore dogru olabilir, ama Debiana göre dogru degil (mi?) :) -common -doc -all gibi soneklerin her zaman ne is yaptigi bellidir. Biz paketimize belgeler ismini verdik diye bir de belgeler-ortak yapamayiz (Yapsak daha þýk gözükür ama.. :( Bu konuyu bir miktar da debian-mentors listesinde tartismakta fayda var. Dokuman dizinlerine gelince, burada hangisi daha iyi olur diye karar veremiyorum bir turlu :) /usr/share/doc/belgeler altinda html, text, misc gibi dizinler acip, her bir dizin altina da hangi paketten cikarsa ciksin belgeleri atabiliriz. (Simdilik tercihim bu yonde) (Belge sayisi cok arttiginda bu mantikta zorlanabiliriz, onu da dusunmek lazim) Veya ornegin belgeler-nasil gibi bir paket icin /usr/share/doc/belgeler altina once bir NASIL dizini acar ve html, text, misc dizinlerini de bunun icinde olusturabiliriz. Birincisinde dokumanlara erisim formata gore daha hizli olacakken ikincisinde paket adina, sinifina gore daha hizli olacak. Belgeleri doc-base sistemine register etmek te mutlaka yapacagimiz bir is ancak belki ilk asamada degil. Asil onemli olan kararlari verdikten sonra her bir paket icin ilgili doc-base dosyalarini olusturmak en kotu bir saatlik is. > > 1) Oncelikle `belgeler' paketinin orig source`unu degistirelim, dogrudan > CVS kullanalim. > > 2) Nilgun hanimin izah ettigi sekilde checkout yapildiginda `sitesrc' > indirilmis oluyor. Bunu `belgeler-cvs20030323' vb. bir sekilde upstream > source yapalim. > > 3) `belgeler' meta paket olmak uzere `multiple' paketleme yapalim. Hangi > dokuman hangi pakette olacak buna karar vermek lazim. `docbook' gibi > `stylesheet'lerin oldugu code dizinlerini atlayarak sitesrc`un sundugu > icerik dizinlerini listeliyorum: > > applications <-- su an sadece python tutorial var > archive <-- man dosyalari burada > howtos <-- HOWTO'lar > others <-- GPL'in cevirisi ve diger felsefi yazilar > sss <-- FAQ > workgroup <-- Belgeler calisma grubuyla ilgili yazilar > xmldict <-- Cevirilerde kullanilabilecek sozluk (cok guzel) > bgnet.xml <-- Beej'in Ag Programlama kilavuzu > html-php-mysql-giris.xml <-- Bu da baska bir kilavuz > > Simdi konulara gore paket onerileri: > > 1) howtos ve sss icin: > HOWTO ve FAQ'lari ayirmak veya ayirmamak uzerinde dusunelim. (Benim oyum > ayrilmamasindan yana) > > Eger ayrilacaksa 2 paket cikar: > belgeler-nasil > belgeler-sss > > Ayrilmayacak ise tek bir paket icine HOWTO ve FAQ'lari koyalim. Bu > paketin ismi icin aklima gelenler: > belgeler-genel/linux/??? > > 2) others icin: > belgeler-cesitli/misc/others? (turkce sozcuklerle ingilizce sozcukleri > karistirmak/karistirmamak?) > > 3) xmldict icin: > belgeler-sozluk/dict? > > 4) workgroup icin: > belgeler-grup/workgroup? > > (3) ve (4) icin bir baska alternatif, bu ikisini tek bir > `belgeler-ortak/common?' paketinde toplamak. > > Digerlerine gelince. Onlarin hepsi kendi basina paketler olsun. Mesela > `applications'daki `python' `belgeler-python'da, Beej'in Ag kilavuzu > (ceviriye yeni baslandi) kendi basina bir pakette vesaire. Nilgun hanim > `archive'deki man dosyalarinin eski oldugunu soyluyor. O halde simdilik > bu dizini atlayalim. > > Son olarak butun bunlarin ustunde iki paket: > > * `belgeler': `/usr/share/doc/belgeler' dizinini kuran ve diger butun > paketlerin `Depends' verdigi meta paket. > > * `belgeler-all': Hepsini kuran paket. > > Ayrica `belgeler-common/ortak' vb. birsey gerekir mi bakmak lazim. > > Kullaniciya 3 tip format sunalim: `html', `text' ve `other' (pdf, ps) > Yani ornek verecek olursak `belgeler-genel' icin `belgeler-genel-html', > `belgeler-genel-text', belgeler-genel-other' gibi. Butun bu paketler su > dizin altina kurulum yapsin: > > /usr/share/belgeler altinda > NASIL > (ornek olarak bunu aciyorum) > html/ > text/ > pdf-ps dosyalari ek dizin acmadan buraya veya ek bir other dizini acarak > onun altina > > SSS > sozluk > cesitli > > Bu konuda diger bir alternatif su olabilirdi: > /usr/share/belgeler altinda > html > text > other > > Ve bunlarin altinda paket dizinleri. > > Ben burada `text' donusumu denedim. Nilgun hanimin dedigi gibi `lynx' > yerine tablo destekli bir text-browser (ben `w3m'i kullandim) cok guzel > sonuc veriyor. > > Bir de su husus var. Butun bir dokumantasyonu `doc-base' ve > `scrollkeeper'a kaydetmek guzel olurdu. (Bu ekleme en azindan bir > sonraki versiyonlarda yapilabilir.) > > Dogal olarak bu tip bir paketleme all-in-one'a gore cok daha fazla vakit > alir. Dolayisiyla once `all-in-one'mi `per-package'mi karar vermek > lazim. Ne diyorsunuz? > > -- > roktas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
