Genelde Linuxda yazılımlar kaynakkodu halinde bulunur. Bu tarz yazılımları sisteme işlemek zor değildir ama silmek istendiğinde sorun yaratabilmektedir. Çeşitli dağıtımlar böyle muhtemelen çıkacak olan sorunları önlemek için kendi paket-menajerlerini kullanmaktadırlar. Paket-yöneticilerinin sunduğu kolaylık sadece yazılımı silmekte değil işlemektede gecerlidir. Kuşkusuz en yaygın olanı Red Hat Package Manageri dir (rpm).

RPM işlediği yazılımların bilgilerini bir hafıyada toplamakla kalmayıp, yazılımların appends lerinide (gereken) kontrol etmektedir. Böylece bir programın istendiği zaman sistemden silinmesi tam olarak mümkün olur. Bu büyük bir avantajdır, herhangi bir program A için gereken bir kütüphaneyi yükleseniz bile bu A programını silerken tereddüt etmeden o kütüphaneyide silebilirsiniz. Tabiki başka işlenmiş bir B yazılım bu kütüphaneye ihtiyaç duymazsa.Eğer program Bde bu kütüphaneye ihtiyaç duyuyorsa, rpm sizi uyarır ve muhtemel bir hatanın olusmasını engellemiş olur

Kendin pişir kendin ye

RPM'in kendimizin kompile ettiğimiz kaynakkodunu yönetbilmesi için kaynakkodundan öncelikle bir paket oluşturmalıyız. Bunun için checkinstall adındaki program kullanılır. Checkinstall kaynakkodu halindeki bir yazılımın yüklenme esnasındaki işlemini kontrol eder ve make install çağrıldığına kopyalanmış dosyalardan bir rpm paketi oluşturur.

Neyazıkki her otomatik çözümde olduşu gibi burdada RPM komutunun bütün olanaklarından yararlanamıyoruz. Mesela chekinstall yazılımları tekli paket haline getiremiyor yada bazı programlarla çalışmayı tamamiyle red edebiliyor.

Farkettiren dezavantaj: Paket için dosyalistesini işlenme esnasında oluşturuyor, böylelikle dosyaların silinmesini kontrol edemiyoruz. Bu eksik gelecekteki olan checkinstall sürğmlerinde RPM-BUILDROOT-opsiyonunun eklenmesi ile giderilecekmiş. Bu seçenek /tmp klasörün yazılımların sisteme işleme esnasında kökdizinesi (/) olarak tanımlıyormuş ve böylelikle dosyaların silinmesini engellemiş oluyormuş.

Yarım işten hoşlanmayan checkinstall gibi ekyazılımlara güvenmeden kendi paketini kendisi oluşturur. Neyazıkki bunun nasıl yapıldığı hakkında rpm-dokumentasyonu (/usr/share/doc) birşey belirtmiyor. Maximum-RPM gibi kaynaklarda yüzlerce sayfadan oluştuğundan hızlı bir başlangıç için ağır kalıyor.

Daha fazla canınızı teorik bilgilerle sıkmadan size bir rpm-paketinin oluşumunu bir örnek üzerinde gösterelim. Örneğimizin adı xpuyopuyo, network-destekli, hoş grafikli ve neşeli bir tetris tarzı oyun.

Hazırlık

Başlamadan önce sistemimizde olan bazı eksikleri gidermeliyiz. Genellikle dağitimlar rpm yüklemek için gerekli olan yazılımları sistemi kurarken yüklüyorlar, ama rpm-paketleri oluşumunda gerekli olan yazılımları eklemiyorlar. Öcelikle sistemimize rpm-build adındakı yazılımı işlemeliyiz. Paket oluşturumunda kullanılan klasröler /usr/src dizinesinin altındadır. Burda rpm-bazlı dagıtımlar ortak bir isimden ziyade ayrı isimler seçmişler. SuSE de /usr/src/packages Mandrakede /usr/src/RPM ve Red Hat'de /usr/src/redhat(ben Red Hat ve Mandrake kullandığımdan bu dağıtımlar altındaki ismini kullanicagim). Asıl paketyapım işlemi redhat klasörünün içinde bulunan diğer 5 klasörde yapılır. Bunların sırayla isimleri şöyledir SOURCES, SPECS, BUILD, RPMS ve SRPMS.

RPMS ve SRPMS klasörlerine biner- ve kaynak-paketleri sonradan yazılır, BUILD klasöründe ise yazılım kompile edilir. RPM oluşumunda gereken komutları siz vermediğinizden, ve RPM'in bunları bir yöneticidosyasından (Specfile) aldığından , bu klasörde sizin yapmanız gereken bir işlem yoktur.

Paketyapicisi SOURCES ve SPECSde hareket eder. SOURCES klasörünün içinde, paket haline getirmeyi amaçladığımız yazılım, tar.gz halinde bulunmalıdır. Eğer kaynakkodunuz tar.gz değilde başka bir formda ise, onu öncelikle tar.gz haline getirmelisiniz.

Eger şuan sistemde root değilseniz su komutu ile geçin. RPM-oluşturma işlemi boyunca superuser (süper-kullanici yani root) haklarına sahip olmalısınız. Örnek programımızı bu linkten indirin http://chaos2.org/xpuyopuyo/xpuyopuyo-0.9.7.tar.gz ve /usr/src/redhat/SOURCES klasörüne kopyalayınız. Sonra SPECS klasörüne geçip orda yöneticidosyası oluşturmalısınız, RPM bu dosyayı şart koşmaktadır. Yönetimdosyasının ismini dilediğiniz gibi verebilirsiniz ama biz kural olmamış standart halini, yani Programadi.spec, tercih etdiğimizden .spec uzantılı bir dosya oluşturduk. Herhangi bir editör ile şimdi bu xpuyopuyo.spec dosyasının oluşumuyla başlıyalım.

Preambel

Specdosyası (yöneticidosya) 3 parçadan oluşur. Preambelin ilk bölümünde genel bilgiler bulunur, mesela oluşacak olan paketin ismi gibi. Xpuyopuyo için preambelimiz Örnek1'deki gibi olabilir.

Specdosyasının yapısı hep aynı olduğundan hazır örnekler ile calışabiliriz. RPM için önemli olan her özellikten sonra bir ":" gelir ve hemen ardındanda bu özelliğin değeri verilir (Copyright: GPL gibi). Name, Version ve Releasee verilen değerlerden paket-ismi oluşur. Version: özelliğinin değeri sadece sayılardan ve noktalardan oluşmalı, aksi taktirde RPM paketoluşumunu iptal eder.

Release özelliği normalde dağıtımlarda hangi paket-sürümü olduğunu belirtir. Sonraki yama-işleminde kolaylık sağlaması için. Bu özelliğin değer aslında dagıtıma-bağlı karakterler içermeli, ama bunu Mandrake dişinda şuan için tam olarak beceren yok. Mandrake dağıtımının paketlerinde daima mdk harflerini paket-isminde bulursunuz. Siz istediğinizi ama oraya değer olarak verebilirsiniz. Bizim örnekte adı "lapis" olarak belirtildi. Verilen değerde eksiişareti (-) gibi simgeler kullanmamaya özen gösterin. Summary de ufak bir tarif yeterli olur, SOURCE özelliğinde ise kaynakkodu arşivinin ismi belirtilmeli. URL de kullanıcılar için paket hakkında Servis-bilgileri bulunur. Böylelikle hemen yazılımın kaynağı belli olmuş olur. Distribution (dağıtım) satırı opsiyonel bir seçenektir, isterseniz boş bıraka bilirsiniz. Packager özelliğinin arkasında en azından takma adınızın yada gerçek isminizin ve geçerli bir e-mail adresinizin bulunmasında fayda vardır. Başka kullanıcılar paketinizi kullandığında keşifettikleri hatalari böylece size bildirme imkanına sahip olurlar.

Group özelliğinde rpm-paketinin yülkenme esnasında, kpackage gibi grafikarayüzlü paketyönetici yazılımlarının, paketin hangi gruba dahil olduğunda belirlemesini sağlar. Teoride buraya istediğimiz ve kendi tasarım ettiğimiz grubisimlerini yazabiliriz, ama oluşturduğumuz paketi dağitmak gibi bir niyetimiz varsa, kullanımda ve yaygın olan grubisimlerini kullanmakta fayda vardır. Bu grubisimlerini /usr/share/doc klasöründe bulunan rpm-dokümatasyonunda GROUP adındaki dosyadan öğrenebiliriz.

Yapımplanı

Specdosyasının başbölümünde programın extract, configure ve install bilgileri bulunmaktadır. Bu bilgiler yazılımdan yazılıma değişebilir, ama genelde tanıdığımız ve kullangimiz şu üçlü kombinasyondan oluşur.

configure

make

make install

Örnek programımız xpuyopuyoda da bu prosedür pek farklı değil. Örnek2'deki satırları Örnek1'e ekleyiniz.

Yüzdelik işaretinin ardından rpm'e şahsi olan kelimeler gelir. %desciption özelliği sonradan rpm -qi xpuyopuyo komutu ile paket hakkında bilgi almak istediğimizde, bize specdosyasının başbölümünün %description özelliğinde tanımlanmış olan bilgileri verir, yani bizim örneğimizde bu komutun çıkışı Tetris benzeri, ağ destekli ve güzel grafikli bir oyun olur. Bu tanım birden fazla satırdan olşuabilir ve harf,işaret ve karakter sınırlaması yoktur.

%prep özelliği %description özelliğini bitirir ve Build-işlemininin başlamasını sağlar. Bu işlem esnasında kaynakpaketinin kompile edilebilinir hale gelebilmesi için gerekli olan herşey yapılır.

%setup özelliği size RPM-yapıcısı olarak Makro kullanımı kolaylığını sunar. Nasıl bir Office-yazılımında devamlı kullanmakta olduğunuz işlemleri Makro olarak kayıt edebiliyorsanız ayni kolayliği RPM'de size sunuyor. RPM'de en cok kullanılan Makro , birden fazla işlemi yönetebilen, Setup-Makro'sudur. SOURCES klasöründe bulunan arşivi BUILD klasörüne extract eder ve otomatik olarak cd komutu ile o klasöre geçer. Eğer bu paketi ilk defa oluşturma cabası değilse, yani öncedende denenmişse, Setup-Makro extract etmeden önce burda bulunan önceki denemelere ait BUILD klasöründe oluşmus olan kompiledenemelerini siler.

%prep'in ikinci satırında asıl yapım işlemi başlıyor. Normalde paketi kompile etmek için ./configure komutunu elinizden vermeniz gerekirdi. --prefix parameteresi, skriptin standart olarak program için bu klasörü seçtiğinden, sadece örnek olarak verildi. Buraya shell´de modife edeceğiniz configure-opsiyonlarını yazmalısınız. Paketi diğer elinizden kompile ettiğiniz yazılımarda olduğu gibi /usr/local klasörüne işlemeniz tavsiye edilir. Böylece belli bir seviyede kendinizin kompile ettiği ve sitem paketleri arasında az da olsa bir fark oluşturmuş olursunuz. Bunu yapmanızın avantajı dağıtımınızın sistem-güncellemesinde paketlerin birbiriyle sorun yaratmamasıdır

Xpuyopuyo'nun tipik --with-gnome=no conigure-opsiyonu, Gnome-pencereyöneticisi için sembol oluşmamsını ve /usr/share'in altındaki dizinelere kopya edilmesini sağlar.

Siradaki %build özelliğinde RPM bu yazılımı kompile eder.Xpuyopuyoda diğer birçok pakette olduğu gibi bu işlemi make komutu gerçekleştirir. Doğal olarak bundan sonraki işlem make install-strip komutu ile kompile edilmiş olan yazılımı /usr/local'e işleyen %install özelliği olmalı.

Strip: Strip komutu binerdosylarından sembolleri ayıklayarak ufalmalarını sağlar. Bu semboller programcılara hataayıklamada (debug) yardımcı olur. nm komutun çıktısında mesela hangi fonksiyonun hangi kütüphaneyi kullandığı gösterilir. Eğer semboller binerdosyalarindan çıkartılırsa, bu dosyalar bir hayli küçülür. Genelde bu nedenden dolayı tüm dağıtımlar stripli programlar sunarlar.

Böylece specdosyasının başbölümü tamamlanmış oluyor. Tabi daha istesek başka özelliklerde ekliye bilirdik. Mesela hata giderici yada yazılıma ayrı özellikler katacak yamaları otomatik olarak işleyen %patch-Makro, yada yazılımı birden fazla pakete, örneğin yazılım.rpm, yazılım.doc.rpm veya yazılım.dev.rpm tarzında bölebilen %package-tanımı gibi. Eğer kütüphane içeren bir paket oluşturacak olursanız, specdosyanıza mutlaka aşağdaki iki satırı ekleyiniz.

%post
ldconfig

Bu özellik paketi yükledikten sonra ldconfig komutunu çalıstırır, ve paketteki yeni işlenmiş kütüphaneyi, program çalıstırıldıgında bulunması için sisteme kayıt eder.

Teoride bir specdosyasının basbölümünde her istediğiniz özelliğe yer verebilirsiniz, fakat paketin yüklenme esnasında sonradan çağrılan bölümlerde (%post özelliği gibi) her Linux-sistemi tarafından tanımlanabilecek komutlar kullanmaya özen gösterin.

Yorucu kısım

Herşey tamam ama rpm hangi doyaları çevıreceğini bilmiyor, çünkü daha örnek yazılımızı makianamıza kurmadık. Önemli olan dosyalara ulaşmanın kısa yolu yok, bazıları rpm`e dönüşecek olan yazılımı makinasına kuruyor ve installwatch yazılımıyla kopya edilmiş dosyaların listesini oluşturuyor. Aynı işlemi checkinstall komutuda görüyor, ama herzaman 100% bir sonuç vermeyebilir. Bazı aşmış arkadaşlar makefile den detay-listesini çıkarıyor. Buna alternatif olarak yazılımı home klasörünün alt klasörlerinden birine yükleyip ya bir özel bash-skripti yazmalıyız yada yüklediğimiz klasörde bir ls -R komutuyla bilgileri kendimiz bulmalıyız. Buna ek olarak spec dosyasındaki path`ları /home/user/XXX den /usr/local/bin`e çevirmeliyiz.

Son yöntemin daha yorucu olmasına rağmen biz bu yolu tercih edeceğiz. Çünkü bu yöntemle kullanıcı olarak yazılımı makinamıza kurduğumuz için hatalı bir Makefile de bulunabilir olan bır rm -rf komutunu yanlışlıkla uygulanmasına şans tanımamış oluruz. Ve böylece build-işlemine dahil olacak paketleri ve kütüphaneleri eklemeyide unutmayız (xpuyopuyo mesela gtk, xpm, XFree, glib ve mikmod paketlerine ihtiyaç duyuyor).

Bazen programı geliştiren şahıs yazılımına bir Spec dosyası dahil edip işimizi kolaylaştırıyor. Ama bu ilk denememiz olduğundan spec dosyasının son kısmını birlikte ekliyeceğiz (Örnek3) :)

%files
/usr/local/man/man6/xpuyopuyo.6
/usr/local/bin/xpuyopuyo
/usr/local/share/xpuyopuyo
%doc /usr/local/share/xpuyopuyo/xpuyopuyo.txt

İlginç olan bizim için son iki satır, /usr/local/share/xpuyopuyo satırında grafiklerin ve sesdosyalarının nereye kopyalanacağı belirtiliyor. Eğer %files bölümünde bir klasör yada dosya tanımlanmışsa bu klasör (yada dosya) pakete tamamiyle dahil edilir. Kesinlikle /usr/local klasörünün buraya yazılmasını engellemelisiniz ;).

Son satırdaki %doc kelimesi ardından gelen dosyayı dokümentasyon olarak tanımlıyor. Bu dosyayı rpm -qd xpuyopuyo komutunu kullandığımızda bizye çıktı olarak verir. Bu %doc-Tag`ın başka bir kullanımıda make install komutunun bir yazılımda eklemediği dokümentasyonları

%doc README FAQ CREDITS

eklentisiyle rpm`i kurarken, bu dosyayı defaultdocdir olarak pakete dahil eder. defaultdocdir dosyası dağıtımdan dağıtıma değişiyor. Red Hat ve Mandrake dağıtımlarında /usr/share/doc SuSE`de /usr/share/doc/packages klasörlerinde bulunuyor. .rpmrc de bulunan öntanımlı değer root-kullanıcı tarafından değıştirilebilir.

Wildcardlar specdosyaının %files bölümünü kolaylaştırır. Eğer bir yazılım /usr/local/share/locale `e yönlendiricidosyalar kopyalıyorsa bu dosyaların tümünü

/usr/local/share/locale/*/LC_MESSAGES/yazılımadı.mo

satırının eklenmesiyle toplayabiliriz. RPM bu işlemde bazı durumlarda (mesela istenilen dilpaktetlerinin olmamasından) hata çıktısı verebilir ama işlemi kesmeden devam eder.

Paketleri bağlamak

Nihayet paketi oluşturmak için hazır durumda. SPECS klasöründe rpm -ba xpuyopuyo.spec komutunu çalıştırınız (Red Hat`de pmbuild -ba xpuyopuyo.spec komutu). -b parametresi RPM`e build-işlemi için gerekli olan yöneticikomutların bir dosyadan okumasını sağlıyor. Dileğimiz build-işleminin sorunsuz ve tamamiyle gerçekleştirmesi. Yani RPM spec-dosyasında sırasıyla tanımlanmış olan işlemleri işlemesi ve biner- ve source-paketleri oluşturması. Bunu -a parametresi gerçekleştiriyor. Source-RPM oluşturmak istemesseniz (yani sadece biner (ix86)) -a parametresi yerine -b parametresini kullanmalısınız, yani rpm -ba xpuyopuyo.spec`in yerine rpm -bb xpuyopuyo.spec parametresi. rpm -bc xpuyopuyo.spec parametresiyle paketin oluşturulup oluşturulamadığını kontrol edebiliriy. Bu işlemde spec-doszası %build işlemine kadar işlenir, yani hiçbir dosza kopyalanmaz.

Her parametre kullanımda RPM bize o anki işlemler hakkında ayrıntılı bilgiler verir.

+ cd xpuyopuyo-0.9.5
+ ./configure --prefix=/usr/local
creating cache ./config.cache

+ işaretiyle başlayan çıktılar RPM`in aksiyonlarını gösterir, örneğimizde kaynakkodlu klasöre geçişi (+ cd xpuyopuyo-0.9.5), ve ./configure komutunun uygulanması. Ardından çağgrılan skriptin çıktıları gösterilir. Herşey sorunsuz halolduysa örnek4`e olduğu gibi bir çıktı karşımıza çıkmalı.

Abb. 2: RPM bir biner- ve bir source-paketi oluşturdu.

Başarı haberini almadan önce RPM`in bazı yerlerde hangi paketin neye ihtiyaç duyduğunu kendiliğinden tanımladığını görüyoruz. Bunun için her biner-dosyası için ldd komutu çağrılır. Böylece yazılımın hangi kütüphaneye linklendiğini tespit eder. Yani başka bir değişle xpuyopuyo-paketinde mikmod-kütüphanesi bulunmuyorsa paketin işlenmesi mümkün olmaz. ldd işleminin tanımadığı gerekenleri opsiyonel olan Requires:-tag`ını preambel`e eklemeliyiz. Mutt yazılımı mesela bir lokal mailserver`e ihtiyaç duyuyor, buna bağlı olarak bu paket Requires: mailserver tag`ına ihtiyaç duyar. Requires tag`ının zıttı Provides: tagıdır. Paketlerini özen gösteren bir dağıtım doğal olarak sendmail ve postfix yazılımların preambel`ine Provides:mailserver tagını ekler.

Bitmiş biner paketimiz RPM klasörünün i686 isimli altklasöründe bulunur. Hangi işlemci mimarına paketimizin optime edilmesi dağıtıma bağlıdır. Ama farklı şekilde bir mimar için (mesela i686 için) rpm-komutsatıropsiyonu --target işlemci-tarzı komutuyla paketimizin işlemci-tarzını yeniden belirliyebiliriz.

Spec-dosyasında bulunan make install-strip komutu paketimizi makinamıza kopyalıyor ama paket-listesine dahil etmiyor. Bunun için Yazılımızı listemize ekleyebilmek için rpm -i ../RPMS/i686/xpuyopuyo-0.9.5-apocalypse.i686.rpm komutunu vermemiz gerekiyor. Eğer Spec-dosyasında bulunmuyorsanız tam path'ı vermelisiniz.

Sizinde başınıza belki bir paketin çalışmadığı gelmiştir, oluşturduğumuzun paketinde böyle bir sorun yaratmaması için (mesela bir kütüphane eksik olabilir) önce built-işlemini gerçekleştirdiğimiz makinanın dışında bir makinaya işlemekte fayda var. Hataları böylece engellemiş oluruz.

Bu Döküman için Aytaç Kırmızı'ya Teşekkürler...