Pisi Paketi Oluşturmak

From Lapis Wiki

Jump to: navigation, search
[değiştir]

Pisi Paketi Nasıl?

"actions.py isimli dosya, kaynak koddan bir ikili ve kurulmaya hazır PİSİ paketi oluşturma sürecini tarif eden bir dosyadır. Bu dosya içerisinde beklenen tarifin doğru şekilde yapılabilmesi için paket yapıcının, yapmakta olduğu paketi yeterince tanıması gereklidir. Öte yandan paket yapıcı için bu kaynağın daha önce paketlendiği dağıtımların paket sistemlerinin spec dosyalarına göz atarak hızlı bir şekilde paketin nasıl oluşturulması gerektiğine dair fikir sahibi olması da mümkündür, fakat bunun PİSİ'nin diğer paket yöneticileri ile arasında organik bir bağ olduğu şeklinde yorumlanması yanlış olur; çünkü PİSİ diğer paket yöneticilerinin hiç birisi ile arasında bir ilişki olmayan yeni bir paket yöneticisidir."
Yukardaki alıntı, son güncellemeleri ile içeriği biraz daha genişlemiş olan biricik PİSİ'mizin Actions API'ının dökümantasyonundan. Şimdi beraberce PİSİ için aalib'i paketleyeceğiz ve bu sayede "PİSİ için nasıl paket yapılıyor?" sorusunun yanıtını merak edenlere nispeten ayrıntılı bir yanıt vermiş olabileceğimi ümit ediyorum..
Eğer elimizde aalib'in diğer dağıtımlar tarafından nasıl paketlendiğine dair bir tarif olsa idi işimiz çok kolay olurdu. Neden? "Çünkü aalib'in en doğru şekilde derlenmesi ve inşa edilmesi için neler yapılması gerektiğine dair bir araştırmayı daha önce yapanların tecrübelerinden faydalanmak bizi çok hızlandıracak bir avantaj olurdu" dediğinizi duyaar gibi oluyorum.
Peki. Elimizde (aşağıda) muhteşem ASCII Art kütüphanesi aalib'in ebuid dosyası var. Gördüğünüz gibi paketin derlenmesi ve inşa edilmesi için gerekli bilgiler ve paketle ilgili meta bilgiler bu dosya içerisinde tanımlanmış durumda. Fakat PİSİ bir paket için iki ayrı dosya kullanıyor, ilki ebuild dosyasının altında görebileceğiniz ve oluşturulacak paket ile ilgili bilgilerin bulunduğu ve XML formatındaki pspec.xml dosyası, diğeri de onun altında görebileceğiniz ve Python ile hazırlanmış olan actions.py dosyası (işte bizim Actions API dökümantasyonu bu dosyayı hazırlarken kullanabileceğiniz işlevleri anlatıyor). Şöyle bir yöntem izlemeye karar verdim: aşağıdaki dosyalardaki önemli ya da açıklanması gereken satırların yanına xy şeklinde numaralar koyacağım ve daha sonra o satırların diğer dosyalardaki karşılıklarını işaretleyip aynı zamanda o satırları aralarda açıklamaya çalışacağım.. 
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

IUSE="X slang gpm static"

inherit eutils [1]

MY_P="${P/_/}"
S="${WORKDIR}/${PN}-1.4.0"

DESCRIPTION="A ASCII-Graphics Library" [2]
HOMEPAGE="http://aa-project.sourceforge.net/aalib/"[3]
SRC_URI="mirror://sourceforge/aa-project/${MY_P}.tar.gz"[4]

LICENSE="GPL-2" [5]
SLOT="0"
KEYWORDS="x86 ppc sparc alpha hppa amd64 ia64 mips ppc64"

RDEPEND=">=sys-libs/ncurses-5.1[6]
   X? ( virtual/x11 )
   gpm? ( sys-libs/gpm )
   slang? ( >=sys-libs/slang-1.4.2 )"

DEPEND="${RDEPEND} [7]
   >=sys-devel/autoconf-2.58
   >=sys-devel/automake-1.4"

src_unpack() { [8]
    unpack ${A}
    epatch ${FILESDIR}/${P}-gentoo.diff[9]

    touch * [10]
}

src_compile() {
    # We need autoconf-2.5 and automake-1.4
    export WANT_AUTOCONF=2.5[11]
    export WANT_AUTOMAKE=1.4 [12]

    econf   `use_with slang slang-driver` \ [13]
        `use_with X x11-driver` \
        `use_enable static`

    emake || die [14]
}

src_install() {
    make DESTDIR="${D}" install || die [15]
    dodoc ANNOUNCE AUTHORS ChangeLog COPYING NEWS README* [16]
}
Evet.. Yukarda kırmızı harflerle işaretlenmiş yerleri tanımlamaya başlayalım ve bizim pspec.xml ve actions.py dosyamızda nelere denk düştüklerine göz atalım..


  1. ↑  Bu satırda 9 ile işaretlenmiş olan satırdaki epatch fonksiyonunun kullanılabilmesi ve parametre olan verilen yamanın kaynağa uygulanabilmesi için eutils inherit ediliyor (Portage'in bash betiklerinin birbirlerini inherit etmesi ile oluşan cehennemine bir giriş noktası, fakat bu konumuz değil). Biz, -dökümanı okuyanların zaten biliyor olduğu gibi- yamaların hepsini pspec.xml dosyasında tanımlıyoruz. Bu yüzden bu satırda yapılan işlemler için bizim ekstra bir şey yapmamıza gerek yok, hemen geçiyoruz.
  2. ↑ Uygulamanın açıklaması. Bizim pspec.xml dosyamız içerisindeki Summary ve Description tagları arasında kalan kısımlara denk geliyor. Hemen farkedeceğiniz gibi bu tagların içerisinde xml:lang ile çoklu dil desteği sağlayabiliyoruz.. Bkz: pspec.xml dosyasında Special:4 ile işaretli satırlar.
  3. ↑  Uygulama ile ilgili bilgilere ulaşılabilecek offical web sayfası. Bizim pspec dosyamızdaki Homepage tag'ına denk geliyor, bkz: Special:2. Ayrıca ebuild dosyasının adından alınan bir bilgi de kaynağın adı, pspec dosyasında Special:1 ile işaretli olan satır.
  4. ↑  Kaynağın temin edileceği adres. Biz kaynakları uygulamaların anasayfalarındaki indirme adreslerinden temin ediyoruz, bkz: Special:5. Aynı zamanda bu tag içerisinde arşivin sıkıştırma türü ve sha1sum değerinin de yazılı olduğunu görebilirsiniz (sha1sum değeri konsolda sha1sum dosya komutu ile elde edilebilir, kaynağın doğru şekilde indirildiğine dair bir teminat olarak kullanılır).
  5. ↑  Uygulamanın ana geliştiricisi tarafından belirtilmiş lisansı, bkz: Special:3.
  6. ↑  Uygulamanın çalışma zamanı bağımlılıkları (Runtime Dependencies), bkz: Special:8. Peki bu bağımlılıklardan hangisinin var olup hangisinin olmadığına nasıl karar veriyoruz? Bunun için 13 numaralı maddede anlatılan yöntem yine geçerli.
  7. ↑ Uygulamanın inşa zamanı bağımlılıkları (Build Dependencies), bkz: Special:6 (Ek bilgi: automake ve autoconf'un versionlarının neden slang ya da ncurses gibi belirtilmediğinin yanıtı automake ve autoconf'un belirtilmiş versiyonlarının ayrı bir paket oluşu, buna kafanızı buna takmayın, bu özel bir durum).
  8. ↑  Bu satır ile beraber ebuild dosyası içerisindeki meta işler sona erdi, bu da demek oluyor ki ebuild içerisinden bizim pspec dosyamıza eklemek üzere çıkarabileceğimiz (patch dışında) daha fazla bilgi yok.. Peki pspec içerisinde yer alan diğer bilgiler nereden geliyor? Source section'ı ile Package section'ı arasında ne fark var? Aşağıdaki Files tagı da ne ola ki? gibi sorular sorduğunuzu ümit ediyorum, bunların cevaplarını almak için lütfen PİSİ mimari belgesinin kısmını okuyun.
  9. ↑  Bu satır ile files dizini altındaki, aalib-1.4_rc4-gentoo.diff yaması kaynağa uygulanıyor (bu sırada biliyoruz ya da şimdi öğreniyoruz ki {P} = aalib-1.4_rc4). Biz de hemen bu yamayı pspec.xml ve actions.py dosyalarımızın bulunduğu dizin içerisine files adında bir kasör oluşturuyor ve içine kopyalıyoruz. Daha sonra da kaynak açılır açılmaz uygulanması için pspec.xml dosyamıza gerekli satırı ekliyoruz, bkz: Special:7.
    Bundan sonraki maddeler aciklama aşağıda, actions.py hakkında kısa bir açıklamanın hemen ardından devam ediyor..
 <?xml version="1.0" encoding="utf-8" standalone="no"?>
 
 <!DOCTYPE PISI SYSTEM "http://www.uludag.org.tr/projeler/pisi/pisi-spec.dtd">
 
 <PISI>
      <Source>
         <Name>aalib</Name> [[Special:1]]
         <Homepage>http://aa-project.sourceforge.net/aalib/</Homepage> [[Special:2]]
         <Packager>
             <Name>A. Murat Eren</Name>
             <Email>meren@uludag.org.tr</Email>
         </Packager>
         <License>GPL-2</License> [[Special:3]]
         <IsA>IsA</IsA>
         <PartOf>PartOf</PartOf>
         <Summary>A ASCII-Graphics Library</Summary> [[Special:4]]
         <Summary xml:lang="tr">Bir ASCII-Grafik kütüphanesi</Summary> [[Special:4]]
         <Description>A ASCII-Graphics Library</Description> [[Special:4]]
         <Description xml:lang="tr"> [[Special:4]]
             AAlib, bir ascii sanatı grafik kütüphanesidir.
             Bir görsel bir ekran gibi çalışır, ancak oluşturulan çıktı 
             platform bağımsız olarak ascii karakterler ile gösterilir.
         </Description>
         <Archive type="targz" sha1sum="a11c16b258bf9b64b135858afabc7f3a45222a4a"> [[Special:5]]
                http://downloads.planetmirror.com/pub/gimp/gimp/libs/aalib-1.4rc4.tar.gz
         </Archive>
         <BuildDependencies> [[Special:6]]
             <Dependency>autoconf2_59</Dependency>
             <Dependency>automake1_4</Dependency>
             <Dependency>xorg</Dependency>
             <Dependency>gpm</Dependency>
             <Dependency versionFrom="1.4.2">slang</Dependency>
             <Dependency versionFrom="5.1">ncurses</Dependency>
         </BuildDependencies>
         <Patches>
             <Patch level="1">aalib-1.4_rc4-gentoo.diff</Patch> [[Special:7]]
         </Patches>
         <History>
             <Update>
                 <Date>2005-09-02</Date>
                 <Version>1.4_rc4</Version>
                 <Release>1</Release>
             </Update>
         </History>
     </Source>
 
     <Package>
         <Name>aalib</Name>
         <RuntimeDependencies> [[Special:8]]
             <Dependency>xorg</Dependency>
             <Dependency>gpm</Dependency>
             <Dependency versionFrom="1.4.2">slang</Dependency>
             <Dependency versionFrom="5.1">ncurses</Dependency>
         </RuntimeDependencies>
         <Files>
             <Path fileType="executable">/usr/bin</Path>
             <Path fileType="library">/usr/lib</Path>
             <Path fileType="header">/usr/include</Path>
             <Path fileType="doc">/usr/share/doc</Path>
             <Path fileType="info">/usr/share/info</Path>
             <Path fileType="man">/usr/share/man</Path>
         </Files>
     </Package>
 </PISI>
Artık sizin de bildiğinizi tahmin ettiğim bir şeyi yinelemek istiyorum: actions.py isimli dosya, kaynak koddan bir ikili ve kurulmaya hazır PİSİ paketi oluşturma sürecini tarif eden bir dosyadır. Bu dosya içerisinde beklenen tarifin doğru şekilde yapılabilmesi için paket yapıcının, yapmakta olduğu paketi yeterince tanıması gereklidir. Python programlama diline aşina olanlar, ilk satırlarda modüllerin nasıl import edildiğini hemen göreceklerdir. Bu dosya kendi özelinde üç temel fonksiyonun ifade edilmesinden oluşur, setup, build ve install. Bu fonksiyonlar dışında istediğiniz gibi fonksiyon tanımlayabilirsiniz ve Python programlama dilinin müsade ettiği her şeyi rahatça yapabilirsiniz. Öte yandan PİSİ'nin build sistemi bu üç fonksiyon'u arar ve işletir. Bunlardan en az install'ın olması da yeterlidir, diğerleri eğer gerekmiyorsa kullanılmayabilir.. Şimdi aşağıdaki dosyayı ebuild dosyamız üzerinden gitmeye devam ederek anlamaya çalışalım..
10 ↑  Bu satırda, kaynak dizini içerisindeki her dosyanın son erişim zamanını 'şimdi'ye çekmek için touch komutu tüm dosyalar için işletiliyor. Bizim de yardımımıza shelltools modülümüz içerisindeki touch yetişiyor, bkz: Nos:1.
11 ↑  Burada muhterem ebuild bey, bu paketin derlenmesi esnasında WANT_AUTOCONF ortam değişkeninin değerinin 2.5 olması gerektiğine dikkatimizi çekiyor. Biz de yanıtımızı yine shelltools içerisindeki export fonksiyonumuzla veriyoruz, bkz: Nos:2
12 ↑  Ebuild an geçmiyor ki bizi süprizleri ile şaşırtmasın. Bu paketin sağlıklı şekilde derlenenebilmesi için WANT_AUTOMAKE ortam değişkeninin de 1.4'ü göstermesi icap ediyormuş. -Yılların eskitemediği emektar- export yeniden iş başında, bkz: Nos:3.
13 ↑ Bu noktada ebuild'in bize anlatmaya çalıştığı şey ise şu "bu paketi eğer bu sistemde slang varsa slang-driver ile, X varsa x11-driver ile derle, bir de static derlemek gerekiyor mu bir düşün". Biz sistemimizde X olacağından eminiz, fakat acaba slang var mı? Emin olmak için hepimizin aynı dili konuşması ve sistemde nelerin desteğinin olacağı ve nelerin desteğinin olmayacağı bilgisini tutan svn'imizdeki make.conf dosyamıza bakıyoruz (aynı yöntem bağımlılıklardan hangilerine sahibiz sorusuna cevap verirken de bize yardımcı oluyor). Basit bir arama ile görüyoruz ki slang var ve static'in başında bir - işareti var. Anlıyoruz ki static'lik bir durumumuz yok, slang ve X ile yola devam. Toparladığımız bu bilgileri dillendirmek için imdadımıza autotools modülü içerisindeki configure yetişiyor ve ortaya Nos:4 çıkıyor.
14 ↑  Bu satırla beraber anlıyoruz ki uygulamamızın inşa edilmesinin vakti gelmiş. Sahneye yine autotools modülü bu sefer de make işlevi ile çıkıyor: Nos:5
15 ↑  Bu noktada yeni bir şey öğreniyoruz, ${D} gösterimi hedef dizine tekabül ediyormuş (ayrıca buraya kadar okumuş olan sabırlı okurlarımız bu tip konularda kendilerine yakalandıkları her noktada bilgi vermekten memnuniyet duyacak SÇO ve meren kullarının varlığından bir kez daha haberdar ediliyorlar). Ebuild bize diyor ki, bu paketi şimdi kuracağız. Fakat bu kurulumun nereye yapılacağını da DESTDIR değişkeni ile make'e söyleyeceğiz ki, gidip kök dizinimize kurmasın, çalışma dizinimiz içerisindeki install isimli dizine kursun (bu ${D} de orayı gösteriyor işte). Bu tip dinamik ya da statik değişkenlere erişmemiz için neyse ki bir get modülümüz var ve bu modül içerisinde de bizim install dizinimizin yerini bize söyleyecek olan bir installDIR işlevi var. Autotools bu sefer de rawInstall işlevini karşılık beklemeksizin bize sunarken yazar, install ve rawInstall işlevleri arasında ne fark olduğu bulmacasının çözümünü okurlara bırakıyor; şiddetle bkz: Nos:6.
16 ↑  Son satırda, kurulan uygulamanın eksik kalan dökümanları kurulum dizinine pakete girebilmeleri için atılıyor. Sıra normalde sürekli yardımına başvurduğumuz fakat bu pakette hünerlerini pek fazla ortaya koyamamış olan, Actions API'mizin Dwarf'ı pisitools modülüne ve emektar dodoc işlevine geliyor, bkz: Nos:7.


Evet.. pspec dosyamızı oluşturduk, action'larımızı yazdık. Şimdi paketi build etme vakti geldi. 
#!/usr/bin/python
# -*- coding: utf-8 -*-
#
# Copyright © 2005  TUBITAK/UEKAE
# Licensed under the GNU General Public License, version 2.
# See the file http://www.gnu.org/copyleft/gpl.txt.
#
# A. Murat Eren <meren@uludag.org.tr>

from pisi.actionsapi import autotools
from pisi.actionsapi import pisitools
from pisi.actionsapi import shelltools
from pisi.actionsapi import get

WorkDir = "aalib-1.4.0"

def setup():
    shelltools.touch("*") Nos:1
    shelltools.export("WANT_AUTOCONF", "2.5") Nos:2
    shelltools.export("WANT_AUTOMAKE", "1.4") Nos:3
    autotools.configure("--with-slang-driver --with-x11-driver --disable-static")Nos:4 

def build():
    autotools.make() Nos:5

def install():
    autotools.rawInstall("DESTDIR=%s" % get.installDIR()) Nos:6
    pisitools.dodoc("ChangeLog", "AUTHORS", "NEWS", "README*", "COPYING") Nos:7
Evet, artık her şey hazır olduğuna göre bu uygulamanın PİSİ paketini ortaya çıkarma vakti gelmiş demektir.. İşte sizler için konsolumdan aldığım build ve ardından kurulum işlemi çıktısı: 
pardus aalib # ls
actions.py  files  pspec.xml
pardus aalib # ls files/
aalib-1.4_rc4-gentoo.diff
pardus aalib # pisi build pspec.xml
Output directory: .

PISI kaynak paketi inşa ediliyor: aalib
Kaynak indiriliyor:  http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/distfiles/aalib-1.4rc4.tar.gz
aalib-1.4rc4.tar.gz            100%        11.79 KB/s
Kaynak arşivi saklandı:  /var/cache/pisi/archives/aalib-1.4rc4.tar.gz
Arşiv açılıyor... açıldı (/var/tmp/pisi/aalib-1.4_rc4-1/work)
 * Yama uygulanıyor: aalib-1.4_rc4-gentoo.diff
Kaynak kuruluyor...
Kaynak inşa ediliyor...
Yerleştiriliyor...
Semboller temizleniyor...
  * Paket aalib inşa ediliyor
files.xml yaratılıyor,
metadata.xml yaratılıyor,
 * PISI paketi aalib-1.4_rc4-1.pisi yaratılıyor.
Bitti.
pardus aalib # ls
aalib-1.4_rc4-1.pisi  actions.py  files  pspec.xml
pardus aalib # pisi install aalib-1.4_rc4-1.pisi
aalib, versiyon 1.4_rc4, sürüm 1, inşa 0 yerleştiriliyor.
Aynı versiyona sahip paketi yeniden yerleştireyim mi?(evet/hayır) evet
aalib için kaldırma-öncesi betiği çalıştırılıyor.
aalib'in COMAR betikleri kayıttan siliniyor.

Dosyalar arşivden çıkartılıyor.
files.xml saklanıyor,
metadata.xml saklanıyor
aalib için yerleştirme-sonrası betiği çalıştırılıyor.
pardus aalib #
Build ile ilgili bir miktar daha bilgi vermek hem PİSİ'nin işleyişi hem de pspec içerisinde var olan ve yanıtsız kalmış olan bazı kısımlar ile ilgili bilgi sahibi olmanız açısından iyi bir fikir gibi görünüyor.Peki, deneyelim.


Bir soru ile başlamak ve onun yanıtını vermeye çalışmak bence her zaman iyi bir yöntem olmuştur bir konunun anlatılmasında ve anlaşılmasında. Çünkü bir sorunun yanıtını verebilmek ve verilen yanıtı anlayabilmek için bu yanıt çevresindeki bileşenleri de az çok anlatmak / anlamak gerekir. Tamam, ucuz felsefeyi kesiyor ve 5 puanlık uzman sorumuzu soruyorum: "Files tag'ı arasında kalan path tanımlamaları nedir?" Bunu iyi bir şekilde anlatabilmek için önce PİSİ'nin bir kaynaktan paket oluşturma sürecinden bahsetmek gerek. PİSİ istemcisi, kendisine build komutu bir pspec.xml dosyası ile beraber verildiği zaman özetle ve kısaca aşağıdaki işlemleri yapıyor:


  • Arşiv dosyasını çekiyor ("/var/cache/pisi/archives/" dizinine).


  • Arşiv dosyasını açıyor ("/var/tmp/pisi/paket_adı/work/" dizinine).


  • pspec.xml içerisinde adreslenmiş yamaları kaynağa uyguluyor. Ve burdan itibaren bir süreliğine pspec.xml ile işimiz kalmıyor.


  • actions.py içerisindeki setup fonksiyonu çalıştırılıyor ve inşa öncesi yapılandırma işlemleri gerçekleştiriliyor.


  • actions.py içerisindeki build fonksiyonunu çağırıyor ve uygulamanın kaynak kodu inşa ediliyor..


  • actions.py içerisindeki install fonksiyonunu çağırıyor, -ve film bundan sonra kopuyor-, inşa edilmiş olan uygulama için install işlemi esnasında bir kurulum gerçekleşiyor. Fakat bu kurulum gerçek sistem yerine "/var/tmp/pisi/paket_adı/install/" dizininin altına, paketin gerçek sistemdeki görüntüsünü görebileceğiniz şekilde kuruluyor. Hatta bizim aalib örneğimizden gidecek olursak aynen şöyle görünüyor: 
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ pwd
/var/tmp/pisi/aalib-1.4_rc4-1/install
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ ls
usr
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ ls usr/
bin  include  lib  share
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ ls usr/share/
aclocal  doc  info  man
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ ls usr/bin
aafire  aainfo  aalib-config  aasavefont  aatest
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $ ls usr/include
aalib.h
meren@pardus /var/tmp/pisi/aalib-1.4_rc4-1/install $
  • Bu noktadan sonra PİSİ, actions.py ile işini bitirip yine pspec.xml dosyasından alınan bilgilerle bir takım işle yapmaya kaldığı yerden devam ediyor. Burdan sonraki adımlar, pspec.xml dosyası içerisindeki her bir Package tagı için birer birer işletilirken sizin de aklınıza muhtemelen "Biz bir tane Source bir tane de Package tagı gördük, birden fazla Package nerden çıktı?" sorusu takılıyor. Peki, o zaman sonraki adımdan bahsetmeden önce bunu aydınlatalım. PİSİ, Source tagı içerisinde tanımlanan özelliklerdeki bir kaynaktan birden fazla ikili paket üretebiliyor. Kaba hatları ile bir pspec.xml dosyası aşağıdaki gibi görünüyor. İşte Package taglarının altındaki Files tagı altında verilen bilgilerin değeri de bu ayrı ayrı paketlerin oluşturulması sırasında ortaya çıkıyor. Çünkü Files tagı içerisinde verilen bilgi PİSİ'ye, oluşturulacak ikili .pisi paketlerinin içerisine bizim kurulum yaptığımız dizin içerisinde oluşmuş olan hangi dizinlerin ya da hangi dosyaların, hangi sıfatla ekleneceğini anlatıyor. Bu bilgilerin ardından daha önce verdiğim aalib örneğindeki pspec.xml dosyasına baktığınız zaman sıfat konusu da aydınacaktır diye tahmin ediyorum. Şimdi iyice basit şekilde söylemek gerekirse Files tagı şu işe yarıyor: Örneğin bizim uygulamamız inşa edilip install dizinine kurulduğunda ortaya A, B, C ve D klasörleri çıkıyor. Biz A ve C klasörlerinden oluşan bir paket, B ve D klasörlerinden oluşan başka bir paketimiz olsun istiyoruz (diyelimki aalib.pisi ve aalib-doc.pisi gibi iki ayrı paket), işte bu isteğimizi ilgili Package altındaki Files tanımlamaları ile elde ediyoruz. Örneğimizi de verdiğimize göre aslında bu yazı amacına ulaşmış oluyor fakat sonrasında neler olduğundan da bahsetmekten zarar gelmez. Peki. Bu maddeden sonraki maddeleri okurken söyleyeceğim şeylerin her birinin Package tagı altındaki her tanımlı paket için bir kez yapıldıklarını anımsayın. 
<PISI>
     <Source>
         (...)
     </Source>

     <Package>
         (...)
     </Package>

     .
     .
     .

     <Package>
         (...)
     </Package>
 </PISI>
  • PİSİ burdan sonra pspec.xml içerisindeki Package tagı altında bulunan AdditionalFiles tagında adreslenen dosya varsa kurulum dizini içerisindeki gerekli yerlere kopyalıyor.


  • Paket için files.xml dosyası yaratılıyor. "Bir de files.xml dosyası çıktı başımıza" dediğinizi duyaar gibi oluyorum. Bu dosya, bu hazırlanan paket ile beraber sisteme gelecek olan tüm dosyaların bilgilerinin tutulduğu dosya. Harika bir dosyadır ve size başka paket yöneticilerinin sağlayamadığı bir kolaylığı sağlar. Bu dosya içerisinde var olduğunu söylediğim bilgiler şunlardır: Path (dosyanın nerede duracağı), Type (bu dosyanın ne tür bir dosya olduğu), Size (dosyanın byte cinsinden boyutu), SHA1Sum (dosyanın SHA1 özeti). Böylece siz sisteminizdeki bir paket için "şu paketle gelen tüm config dosyalarını göster" sorgusunu kolayca yapabilirsiniz. Güzide files.xml dosyasından bir girdi örneği verelim de tam olsun bari: 
(...)
  <File>
      <Path>
          usr/lib/libaa.so.1
      </Path>
      <Type>
          library
      </Type>
      <Size>
          113924
      </Size>
      <SHA1Sum>
          9a32f0a02c49e643a4ece41679bda26a5b3cc066
      </SHA1Sum>
  </File>
  (...)
  • files.xml dosyası da oluşturulduktan sonra sıra metadata.xml dosyasına gelir. Bu dosya da pspec.xml'in hem Source hem de Package tagları içerisinde kalan bilgilerden derlenmiş olan bir dosyadır ve -adından da tahmin ettiğiniz üzere- oluşturulacak paketin kurulacağı sisteme geldiği zaman iş görecek meta bilgilerini tutar: paketin adı, versiyonu, bağımlılıkları, açıklaması, kurulduğundaki boyutu filan gibi.


  • Son olarak da paket için Files altında tanımlanmış dizinler, metadata.xml dosyası, files.xml dosyası ve varsa yine AdditionalFiles altında adreslenmiş olan ÇOMAR betikleri bir araya getirilip zipleniyor ve ortaya .pisi uzantılı bir kurulabilir paket çıkıyor..


Şimdilik bu kadar..



Tüm bu bilgilerin ardından siz de paket yapmak istiyor olabilirsiniz. Bunun için belki bir miktar daha actions.py ya da pspec kurcalamak istiyorsunuzdurya da belki biraz cesaretlendirilmeye ihtiyacınız vardır, bilemiyorum. Fakat şunu bilmelisiniz ki, paket geliştiricileri bir dağıtımın belkemiğini oluşturur ve her dağıtım gibi Pardus'un da paket geliştiricilerine ihtiyacı var. Gelin, biz sizi cesaretlendirelim, takıldığınız yerlerde yardım edelim ve bu işin altından beraber kalkalım. İzlemeye ara verip Pardus'un bir parçası olun, çok yüksek olasılıkla size fazlasını iade edecektir. Ya da sadece izleyin, biz sizi yine de seviyoruz :)



A. Murat Eren (meren at uludag.org.tr)
Retrieved from "http://wiki.linux-sevenler.org/index.php/Pisi_Paketi_Olu%C5%9Fturmak"