Re: Belgeler-html paketi
> `/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 debian-user-turkish-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: