| Synopsis: Spec dosyası, " öykünülmüş" veya "sanal" bir derleme ve kurulumun nasıl yapılacağını tanımlarken RPM' e bu kurulumdan hangi dosyaların paketleneceğini ve kullanıcının sistemine nasıl kurulacağını gösterir. Çalıştırılan komutlar /bin/sh kabuğu komutlarıdır.
|
Zamanla, daha fazla RPM paketi oluşturdukça kullanabileceğiniz bir çok özellik olduğunu keşfedeceksiniz.
Şimdi, örnek rpm .spec dosyamızı ele alalım:
| Note: Buradaki .spec dosyası gerçek bir paket oluşturmakta kullanılmamıştır. Örnek olması ve spec dosyasını mümkün olduğunca iyi açıklamak amacıyla tasarlanmıştır. |
Dosya: abc.spec
Dosya Konumu: ~rpm/SPEC/abc.spec
%define name abc
%define version 2.0.1
%define release %mkrel 1
%define libname %mklibname %{name}
Name: %{name}
Summary: Tools for converting websites from using GIFs to using PNGs
Version: %{version}
Release: %{release}
Source0: http://www.xxxx.org/abc/%{name}-%{version}.tar.bz2
Source1: %{name}-%{version}-mdk-addon.tar.bz2
Patch0: abc-2.0.1-bugfix.patch
URL: http://www.xxxx.org/abc/
Group: Applications/Multimedia
License: GPLv2+
BuildRequires: libxyz-devel
BuildRequires: lib123-devel >= 1.2
Obsoletes: abc-svn
Provides: abc-svn
Requires: python
Requires: libabc
Suggests: libqwe
Conflicts: libdef
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
%description
Tools for converting GIFs to PNGs. The program abc converts GIF files
to PNG files. The Python script def2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.
%package -n %{libname}
Summary: Library files for abc
Group: System/Libraries
%description -n %{libname}
These are common library files for abc
%package -n abc-examples
Summary: Example files to use with abc
Group: Applications/Multimedia
Requires: abc = %{version}-%{release}
BuildArch: noarch
%description -n abc-examples
Example files to use with abc.
%prep
%setup -q -a 1
%patch -p1
%build
%{configure}
%{make}
%install
rm -rf %{buildroot}
%{makeinstall}
%clean
rm -rf %{buildroot}
%files
%defattr(0755,root,root)
%doc README NEWS COPYING AUTHORS
%{_mandir}/man1/abc.1*
%{_mandir}/man1/def2png.1*
%{_bindir}/abc
%{_bindir}/def2png
%files -n %{libname}
%defattr(0755,root,root)
%{_libdir}/libabc.so
%files -n abc-examples
%defattr(0755,root,root)
%{_datadir}/abc/*.txt
%changelog
* Mon Nov 02 1999 Ahmet Mehmet <ahmeh@mageia.com> 2.0.1-1mga
- Upgraded to 2.0.1
* Mon Oct 25 1999 Ahmet Mehmet <ahmeh@mageia.com> 2.0.0-1mga
- Specfile adaptations for Mageia
- add python requirement
| Not Edin!: Bir satırın başındaki % işareti bir çok anlama gelebilir:
|
| Warning! RPM Spec dosyaları mutlaka UTF-8 karakter kodlaması kullanılarak hazırlanmalıdır!
|
Contents
Başlık Bölümü
%define name abc
%define version 2.0.1
%define release %mkrel 1
%define libname %mklibname %{name}
İlk üç satır, spec dosyasının daha sonraki bölümlerinde de kullanılan tanımları (değişkenleri) ifade eder: %{name}, %{version} ve %{release} . %mkrel, Mageia' ya özgü bir makro olup, paket adındaki yayım numarasından sonra "mga" etiketini ekleyen makrodur.
| Not Edin!: %define makrosu spec dosyasında kullanılacak bir değişkeni tanımlamakta kullanılır. Mutlaka .spec dosyasının en üstünde yer almalıdır. |
Bu kısımda bir dördüncü tanım (%define ) daha görüyorsunuz:
%define libname %mklibname %{name}
Bu tanım libname adını verdiğimiz bir paketin adını tanımlıyor. Bu paket ise abc uygulamasının kütüphane dosyalarını içerecek ikinci bir pakettir. %mklibname makrosu da özel bir makro olup, lib (x86_64 sistemlerde lib64) takısını paket adının önüne ekleyecektir.
| Not Edin!: RPM paketlerinin oluşturulmasındaki bir kolaylık da tek bir .spec dosyasında birden çok paketi tanımlayarak, tek bir kaynaktan birden çok paket oluşturabilmemizdir. Örneğimizde, abc-2.0.1-1mga.i586.rpm, libabc-2.0.1-1mga.i586.rpm, abc-examples-2.0.1-1mga.noarch.rpm paketleri bir tek bu .spec dosyasından oluşacaktır. |
Bu şekilde rpm spec dosyasını doldurmaya başlarız:
Name: %{name}
| Note: "%{name} " , spec dosyası başında gördüğümüz %define ile tanımlanmıştır. |
Version: %{version}
Release: %{release}
Öncelikle buradaki ifadelerin anlamlarını verelim:
- Name (İsim): Paketin adı olacak isim bölümünü ifade eder. Genellikle, paketlenecek uygulamanın özgün adının küçük harflerle yazılmış hali olur.
| Not Edin!: Önemli bir nedeniniz yoksa paket adı olarak uygulamanın özgün adını kullanın. Ancak, mesela benim kde3 paketlerinde (kde4 paketleri ile karışmaması için) yaptığım gibi farklı bir ad kullanılabilir. K3B uygulaması hem KDE4 hem de KDE3 için var olduğundan, kde3 sürümü "kde3-k3b" adı ile paketlenebilir. |
- Version (Sürüm): Paketlenen uygulamanın özgün sürüm numarasıdır.
- Release (Yayın): Paketimizin sürüm numarasıdır. Madeia Linux paketlerinde, "mga" ibaresinin hemen önündeki ibaredir. Bu şekilde, pakette herhangi bir değişiklik yaptığımızda (mesela yeni bir yama uyguladığımızda veya yeni bir simge eklediğimizde) yeni paketin kaçıncı sürüm olduğunu gösterir. Her paket içeriği değişikliğinde bu "yayın" numarası da artarak değişir.
| Not Edin!: Yukarıdaki açıklamalarımıza göre bir paketin tam ismi şu biçimde şekillenir:
|
Summary: tools for converting websites from using GIFs to using PNGs
- Summary (Özet): Bu, paket hakkında tek cümlelik özet bilgi verilen kısımdır.
Source0: http://www.xxx.org/abc/%{name}-%{version}.tar.bz2
- Source0 (Kaynak): Bu satır, hangi kaynağın paketi oluşturmakta kullanılacağını gösterir. RPM, buradaki bağlantıyı ayrıştırarak kaynak olarak kullanılacak arşivi veya dosyayı
SOURCESdizininde arar ve kullanır.
- Birden fazla kaynak kullanılacaksa her biri ayrı satırlar halinde ve Source1: ..., sonra Source2: ..., şekinde gösterilir.
| Not Edin!: * Source0 ibaresinin 0 (sıfır) rakamı ile başladığına dikkat edin.
|
Patch0: abc-2.0.1-bugfix.patch
- Patch0 (Yama): Paket derlenirken uygulanacak yamaları belirten satır. Bu satır, sadece yama uygulanacaksa .spec dosyasında yer alır.
| Not Edin!: Yama dosyası (patch) mutlaka SOURCES dizininde bulunmalıdır; rpm, yamaları da bu dizinde arar. Tıpkı Sources satırındaki gibi yamalar da 0 rakamından başlayarak Patch1, Patch2, ... şeklinde gösterilirler.
|
URL: http://www.xxxx.org/abc/
- URL (Ağ adresi): Paketlenecek uygulamanın İnternet adresidir.
Group: Applications/Multimedia
- Group (Grup): Bu satır ile paketin hangi uygulama grubuna dahil olduğu belirtilir. Bu gruplar paket yöneticileri tarafından kullanılır. Mesela, Mageia Linux yazılım yöneticisi (rpmdrake) arayüzünde sağ yandaki gruplar bunlardır.
Mageia Linux paket gruplarını Paket grupları sayfasında bulabilirsiniz.
License: GPLv2+
- Licence (Lisans): Bu satır, paketlenen uygulamanın sahip olduğu lisansı gösterir. Buradaki lisans, daha önce de belirtildiği gibi; paketlenen uygulamanın lisansının uygulamanın yeniden derlenmesi, paketlenmesi ve yeniden dağıtımına izin veren bir lisans tipi olmalıdır. Mageia Linux paketlerinde kullanılan ve geçerli sayılan lisanslar için Lisanslama Kuralları] sayfasına bakınız.
BuildRequires: libxyz-devel BuildRequires: lib123-devel >= 1.2
- BuildRequires (Derleme Bağımlılığı): Bu satır, pek çok uygulamanın paketlenmesinde kullanmak zorunda kalacağımız bir satırdır. Paketlenecek uygulamanın derlenebilmesi için gerekli geliştirme kütüphaneleri ve diğer bağımlılık paketlerini gösterir. Her bir bağımlılık için ayrı bir satır yazılır.
| Not Edin!: Genellikle, acemi paketleyicilerin karşılaştığı en büyük sorun, bu derleme bağımlılıkları kısmıdır. Hangi ek paketlerin, derleme için zorunlu olduğunu bulmak çok önemlidir. Aksi takdirde paket hazırlayamayız. Bu sorunu çözebilmek biraz sabır isteyen bir iştir. Emin olun, daha kolay bir yöntemi de yoktur:
Derleme bağımlılık paketleri, Mageia Linux ve diğer RPM temelli dağıtımlarda genellikle
|
komutunu verin. Configure betiği eksik bağımlılığı size bildirecektir. Siz de yine benzer şekilde bağımlılığı kurun.}}
Obsoletes: abc-svn Provides: abc-svn
- Obsoletes (Gereksiz hale getirdikleri): Bu satır, paketlenen uygulamanın abc-svn' nin işini ve daha fazlasını gördüğünü; bu paketin kurulması ile abc-svn' ye artık gereksinim duyulmadığını gösterir.
| Örnek: Mageia Türkiye depomuzda bulunan nautilus-elementary paketi bu tanımlar kullanılarak oluşturulmuştur. Hem nautilus' un görevini tam olarak görmekte ve nautilus' a ek bazı özellikler sunmaktadır. Obsoletes tanımı sayesinde, herhangi bir dosya çakışması olmadan sanki bir yükseltme imiş gibi kolayca nautilus' un yerini alabilmektedir. |
- Provides (İşlevini sunduğu paketler): Bu satır, paketlenen uygulamanın abc-svn' nin işini ve daha fazlasını gördüğünü göstermek ve abc-svn' ye bağımlı olan başka paketlerin (oluşacak eksik bağımlılık nedeniyle) sistemden kaldırılmasının önüne geçmek için kullanılır.
| Warning! Obsoletes tanımının kullanıldığı durumlarda mutlaka Provides tanımı da kullanılmalıdır. Aksi halde gereksiz hale gelen eski paketin rpm tarafından sistemden kaldırılmış gibi algılanması meydana gelecek ve (oluşacak eksik bağımlılık nedeniyle) bağımlı diğer paketleri de sistemden kaldırmaya çalışacaktır. Provides tanımı ise Obsoletes tanımı kullanılmaksızın tek başına kullanılabilir. |
Requires: python
- Requires (Bağımlılık): Bu satır paketlenen uygulamanın çalışması için gerekli bağımlılıkları gösterir. Her bir bağımlılık için ayrı bir satır yazılır.
| Ipucu: Paketlediğiniz uygulama bir bağımlılığın belirli bir sürümünü gerektiyorsa Requires ve BuildRequires satırlarındaki bağımlılıklar şu biçimde gösterilir: Requires: python >= 1.5.1
Requires: python = 1.5.1
Requires: python <= 1.5.1
Requires: python < 1.5.1
Requires: python > 1.5.1
|
Suggests: libqwe
- Suggests (Önerir): Bu satır, oluşturulacak paketin kurulmasını size önerdiği ek paketleri tanımlamak için kullanılır. Önerilen paketler, uygulamanın çalışması için zorunlu bağımlılıklar olmayıp kurulması isteğe bağlı, uygulamaya ek özellikler katan paketlerdir.
Conflicts: libdef
- Conflicts (Çakışanlar): Bu satır, oluşturacağımız paketin çakışma yaşadığı; yani abc içinde bulunan dosyaların bir kısmının aynı zamanda libdef içinde de bulunduğu; durumlarda kullanılır. Bu sayede paketimiz kurulmadan önce rpm' in kendiliğinden çakıştığı paketi (örneğimizde libdef paketi) sistemden kaldırıldıktan sonra kurulmasını sağlayacaktır. Aksi halde, rpm paketimizin libdef ile çakıştığı uyarısını vererek paketimizi sisteme kurdurmayacaktır.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
- Buildroot (Derleme kök dizini): Bu satır çok önemlidir ve mutlaka örnekteki gibi kullanılmaldır. Bu satır; rpm uygulamayı kaynak kodlarından derlediğinde, dosyaların hangi sahte sistem dizinine (/) kurulacağını gösterir. Daha sonra rpm, buradaki dosyaları paketler.
%description Tools for converting GIFs to PNGs. The program abc converts GIF files to PNG files. The Python script def2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct.
- Description (Açıklama): Bu satır, paketlenen uygulama ile ilgili daha fazla bilgi veren açıklama satırıdır. Kimi zaman tek cümle kimi zaman bir paragraf olabilir. Bu sayede paketi kuracak olan kullanıcıya paket ile ilgili gerekli bilgiler verilir.
| Not Edin!: %description satırındaki açıklama, her satırda en fazla 70 karakter olacak şekilde yazılmalıdır. Bir cümle 70 karaktere ulaştığında, alt satıra geçilerek cümle devam ettirilir. Boşluk ve noktalama işaretleri de karakter sayılırlar ve bu 70 karaktere dahildirler. |
Bu noktada, paet tanımlamaları ve açıklamalarının çevirileri ne olacak sorusunu sorabilirsiniz. Mageia Linux' un geliştirilme ortamında, svn deposuna gönderilen her .spec dosyası ayrıştırılır ve paket açıklamaları için birer çeviri dosyası oluşturulur. Bu sayede, her Mageia paketinin Türkçe açıklamaları yapılabilir. Tabii ki, bu sistem Mageia Geliştirme Ortamı olan Mageia SVN deposu için mümkündür. Kişisel olarak derleyeceğiniz paketler için bu seçenek yoktur.
| Ipucu: Kendi derlediğiniz paketlerde Türkçe açıklama ve özetin de olmasını istiyorsanız;
ibarelerini kullanabilirsiniz. Bununla beraber mutlaka özet ve açıklama bölümlerinin İngilizcesi de .spec dosyasında yer almalıdır! |
%package -n %{libname}
Summary: Library files for abc
Group: System/Libraries
%description -n %{libname}
These are common library files for abc
- Bu kısımda ikinci bir rpm paketini hazırlıyoruz. Önceki açıklamalarımızdan sadece iki farkı var, gördünüz değil mi? Evet, o farkların ilki
%package -n %{libname}
satırı. Birden fazla paket oluşturulacaksa, kullanım bu şekildedir. Dikkat ettiyseniz, Name: satırımız yok. Paket ismini bu belirttiğimiz satır verecek ve paket adımız libabc olacaktır. Bu satır aynı zamanda ikinci bir paketi hazırladığımızı da gösterir.
%description -n %{libname}
satırı ise, tahmin ettiğiniz gibi, bu ikinci pakete ait açıklamalar satırıdır.
%package -n abc-examples
Summary: Example files to use with abc
Group: Applications/Multimedia
Requires: abc = %{version}-%{release}
BuildArch: noarch
%description -n abc-examples
Example files to use with abc.
- Burada da bir öncekine benzer şekilde üçüncü bir paket hazırlıyoruz. Paketimizin adı da abc-examples olacak. Burada da bir önceki tanımlamalara göre tek bir farklı satır var:
BuildArch: noarch
Bu satır, bu paketin (yani üçüncü paketin) herhangi bir işlemci mimarisinde çalışabileceğini gösteriyor. noarch ibaresi yerine işlemci mimarileri de yazılabilir. Mesela, uygulama sadece i586 mimaride çalışmak üzere kodlanmışsa, i586 olarak da kullanılabilir.
| Not Edin!: noarch ibaresini bir pakette kullanabilmemiz için, paketin içerğindeki dosyaların ikili (binary) dosyalar ve kütüphane (*.so) dosyaları olmaması gerekmektedir. |
Prep (Hazırlık - preperation) Bölümü
%prep %setup -q -a 1 %patch0 -p1
Bu bölümde, rpm tarafından çalıştırılacak ilk betik gösterilmektedir. Şu işlemleri gerçekleştirir:
BUILDdizini içerisinde, derleme işleminin gerçekleşeceği bir derleme dizini oluşturulur,- Oluşturulan derleme dizini içerisine kaynak arşivi açılır,
- (Varsa) yamalar uygulanır.
Bu %prep bölümünde, ayrıca uygulamanın derlenebilmesi için paketleyicinin çalıştırılmasını istediği gerekli diğer komutlar yer alır.
| Note: Kaynak arşivinde bir dosya; diyelim ki kaynak arşivinde bulunan src dizinindeki abc.c C++ kaynak dosyası; silinmeli ki derleme bizim istediğimiz gibi olsun. Bu bölümde silme komutu tanımlanır:
%{__rm} -f src/abc.c
Bu tarz komutlar için doğrudan rm -f src/abc.c kullanmak yerine makro kullanımı tercih edilmelidir. Bir başka dağıtımda rm,
|
%setup -q -a 1
Bu bir yerleşik makrodur:
- Kabukta derleme dizinine giriş yapar (cd komutu kullanılarak),
- Kaynak arşiv(ler)ini açar (sessizce, -q anahtarı ile)
- Kaynak dosyaların sahiplik ve izin yetkilerini değiştirir.
Öntanımlı olarak ilk kaynak arşivini açar. Diğer arşivlerin bu dizine açılması için %setup makrosunda ek anahtarlar kullanmalısınız.
| Örnek: Buradaki örneğimizde, -a 1 anahtarı derleme dizinine SOURCE1 kaynağının da açılması talimatını verdik. Buradaki -a anahtarı diğer bir arşivin açılmasını; 1 rakamı da SOURCE1 kaynağını gösterir. |
| Not Edin!: %setup makrosu ile kullanılabilecek diğer bazı anahtarlar şunlardır:
|
%patch0 -p1
Bu makro, yamaların kaynağa uygulanmasından sorumludur. patch yamalama aracına "-p<sayı>" parametresi geçirilir. Diğer yamalar da sırasıyla alt alta aynı biçimde kullanılır. Ayrıca, yamanızın ne işe yaradığını veya yamayı kimin oluşturduğunu burada gösterebilirsiniz. O zaman şu şekilde kullanılır:
%patch1 -p1 -b .yamanın_işlevi_veya_siniz adınız : %patch1 -p1 -b .tarakbumba
Build (Derleme) Bölümü
%build
Bu bölüm, paketlenecek yazılımın derleme ortamında (~/rpm/BUILD dizini) derlenmesinden sorumlu betiği içeren bölümdür.
%{configure}
Bu makro, GNU Autoconf ile oluşturulmuş kaynak kodlarını yapılandırmak ve ./configure işlevini yerine getimek için kullanılır. Bu makro, sadece ./configure işlevini yerine getirmekle kalmaz, ./configure komutuna Mageia Linux sistemi ile ilgili bir çok parametreyi de geçirir.
| Not Edin!: Paylaşımlı kütüphaneleri %configure derleyebilmek için sisteminizde libtool paketi kurulu olmalıdır.
|
Derleme yapılırken, normalde ./configure komutu bilgisayarın işlemci mimarisini bularak uygulamayı buna göre derlemek üzere yapılandırır. Bu takdirde, işlemci mimariniz i686 ise, mesela bir Intel Pentium 4, uygulama buna göre derlenir ve i586 sistemlerde çalışmaz. İşte, %configure makrosu bu sorunun önüne de geçerek Mageia Linux' un temel 32bit mimarisi olan i586' ya göre uygulamanın yapılandırılmasını sağlar.
| Not Edin!: Burada sadece %configure işlenmiş de olsa, daha pek çok farklı kaynak kodu yapılandırma aracı vardır. Örneğin, KDE4 uygulamaları GNU Autoconf yerine cmake kullanır. Cmake kullanan uygulamalarda %cmake makrosu; KDE4 uygulamalarına özel olmak üzere %cmake_kde4 makrosu kullanılır. |
%{make}
Bu basit makro make komutunu yerine getirir. Ayrıca, make komutuna, birden fazla çekirdeği olan işlemcilerin tüm çekirdeklerinin çalıştırılması için gerekli anahtarı ekler: -j<sayı>. Örneğin, Üç çekirdekli AMD Phenom XII işlemci için şu şekilde kullanır:
| $ make -j3 |
xmkmf kullanan kaynak kodları için, %make yerine şu komutu kullanmalısınız:
make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS"
Install (Kurulum) Bölümü
%{install}
Install (Kurulum) bölümü, paket içeriğinin kurulum taklidinin yapıldığı dizine ($RPM_BUILD_ROOT = ~/rpm/BUILDROOT/paket_adı) kurulmasından sorumlu betiği içeren bölümdür.
Bu bölümde, yazılımın kullanıcı sisteminde çalışabilmesi için gerekli komutları içerir.
rm -rf %{buildroot}
Bu komut,%install böülümnde yürütülmesi gereken ilk komuttur. Bu komut daha önceden oluşturulmuşsa, kurulum taklidinin yapıldığı dizini siler. Bu komutun her .spec dosyasında yer alması gerekir. Aksi takdirde, başarısız bir paketleme girişimi sonrası yeniden paketleme yapılmak istendiğinde; hata alınacaktır.
%{makeinstall}
Bu makro, autoconf kullanan kaynaklardan derlenen uygulamanın, kurulum taklidinin yapıldığı dizine (~/rpm/BUILDROOT/paket_adı) kurulmasını sağlayacaktır.
Bu makro, tipik bir "make install" komutunu bir çok ek komut ile birlikte uygulamayı sağlamaktadır.Örneğin:
make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} install
Bazı durumlarda, herhangi bir ek komut belirtilmeden, MAKE dosyalarının kurulum alt dizinini kendilerinin belirlemeleri gerekebilir. Bu tip MAKE dosyaları ile %makeinstall makrosu kullanıldığında, kurulum işlemi doğru olarak gerçekleşmez. O zaman, imdadımıza %makeinstall_std makrosu yetişir. Bu makro, %makeinstall makrosunun aksine, her kurulum dizini için ayrı bir parametre vermez. Tek bir parametre verir ve o da kurulum taklidinin yapıldığı dizinidir:
| $ make DESTDIR=~/rpm/BUILDROOT/paket_adı install |
Tüm bu işlemler sonucunda, paketin içine konulmaya hazır bir yazılım kurulumu elde etmiş oluruz.
Clean (Temizleme) Bölümü
%clean
Bu bölümde derleme dizini (~/rpm/BUILDROOT) temizlenir.
rm -rf %{buildroot}
Bu komut temizleme işlemini gerçekleştirir.
Files (Dosyalar) Böülümü
%files
Bu bölümde, kurulum taklidinin yapıldığı dizinde oluşturulan ve pakete dahil olacak dosyalar listelenir.
Bu dosya listesi .spec dosyasına elle yazılmalıdır. Bu işi, simülasyon dizininde oluşturulan dosyaların adlarını ve konumlarını yazarak yapabiliriz. Kolaylık olması açısından; %files bölümüne kadar .spec dosyasını yazdıktan sonra aşağıdaki komutu çalıştırmanızı öneririm:
| $ rpmbuild -bi mypackage.spec |
Bu komut ile rpmbuild; .spec dosyamızdaki %files bölümüne kadar olan işlemleri gerçekleştirecek ve derlenen dosyaları kurulum taklidinin yapıldığı dizinde (~/rpm/BUILDROOT/paket_adı) oluşturduktan sonra işleme son verecektir. Sonra da tek tek dosyalara bakarak onları listeleyin.
| Warning! Dosyaları komut satırında listelemeye çalışmayın; özellikle find komutunu kullanmayın. Yeni rpm sürümlerinde bu komut hatalı bir liste elde etmenize neden olur. |
| Not Edin!: Uygulamanın çeviri dosyalarını elle yazmanız gerekmemektedir. %install bölümünde %find_lang %{name} makrosunu kullanarak rpm' in kendiliğinden çeviri dosyalarını bulmasını sağlayabilirsiniz. Ayrıca, %files ibaresini %files -f %{name}.lang makrosu ile değiştirin: %install
%find_lang %{name}
%files -f %{name}.lang
%defattr(0755,root,root)
%doc README NEWS COPYING AUTHORS
|
- Daha fazla bilgi için : RPM Makroları sayfasına göz atın.
| Not Edin!: Dizin yapısı : Oluşturduğunuz dosyaları paketin kuracağı dizinler FHS standartlarına uymalıdır. |
%defattr(0755,root,root)
Bu makro, kullanıcının sistemine rpm tarafından kurulacak her dosyanın dosya izinlerini tanımlar.Dört adet anahtar kullanılabilir:
- -: Normal dosyalar için tüm izinler değişmeden kalır.
- root: Dosyanın sahibi olan kullanıcı root (kök kullanıcı) olacaktır,
- root: Dosyanın sahibi olan grup root (kök)grubu olacaktır
- 0755: Bu paket tarafından oluşturulacak tüm dizinlerin izinleri 0755 ( rwxr-xr-x ) olacaktır.
%doc README NEWS COPYING AUTHORS
Bu özel makro (%doc), paketin belgelerini tanımlar.Bu belgeler, /usr/share/doc/abc-2.0.1/ dizinine yerleştirilecektir. Bu dizin rpm tarafından kendiliğinden oluşturulacaktır.
%{_mandir}/man1/abc.1*
%{_mandir}/man1/def2png.1*
Burada her man ve info dosyasını ayrı ayrı listelemeniz önerilir.
Bu kısımda neden abc.1.lzma yerine abc.1* şeklinde kullandığımızı merak edebilirsiniz. bunun sebebi; diğer dağıtımlar için rpm paketi oluşturulmak istendiğinde paketin derleneceği dağıtımın gzip sıkıştırması kullanması durumunda paket inşasında sorun çıkmamasını sağlamaktır.
%{_bindir}/abc
%{_bindir}/def2png
Görebileceğiniz gibi, gereksinim duyacağınız hemen her konum için bir makro kullanılabilmektedir. Bazı önemli konum makroları aşağıda sunulmuştur:
%{_sysconfdir} /etc
%{_prefix} /usr
%{_bindir} %{_prefix}/bin
%{_libdir} %{_prefix}/%{_lib}
%{_libexecdir} %{_prefix}/libexec
%{_sbindir} %{_prefix}/sbin
%{_sharedstatedir} /var/lib
%{_datadir} %{_prefix}/share
%{_includedir} %{_prefix}/include
%{_infodir} %{_datadir}/info
%{_mandir} %{_datadir}/man
%{_localstatedir} /var
%{_initddir} %{_sysconfdir}/rc.d/init.d
%{_docdir} %{_datadir}/doc
%{buildroot} %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch}
$RPM_BUILD_ROOT %{buildroot}
- Fark ettiğiniz gibi %files bölümü devamında diğer iki paketimizin dosyaları ile ilgili biraz farklı %files bölümleri de var. Bir .spec dosyasından birden fazla paket oluşturuluyorsa, ikinci ve sonraki paketlerin %files bölümleri de örnek spec dosyamızdaki gibi yazılır:
%files -n %{libname}
%files -n abc-examples
Changelog (Değişiklik günlüğü) Bölümü
%changelog
Bu bölüm, paket üzerinde yapılan değişikliklerin belirtildiği ve paketin önceki sürümüyle farklarının ortaya konduğu bölümdür. Paket üzerinde yapılan her yeni değişiklikte, (sürüm numarası değişmemişse) yayın numarası yükseltilerek yeni bir paragraf yazılmalıdır. Paragraflarda İngilizce kullanılması gereklidir. Bunun nedeni, başka memleketlerden kişilerin de bu paketi anlamalarıdır. Bu paragraflar şu yapıda yazılmalıdır:
* Mon Nov 02 1999 Ahmet Mehmet <ahmeh@mageia.com> 2.0.1-1mga - Upgraded to 2.0.1 * Mon Oct 25 1999 Ahmet Mehmet <ahmeh@mageia.com> 2.0.0-1mga - Specfile adaptations for Mageia - add python requirement
- Her bir paragraf başı * işareti ile gösterilir.
- Paketin oluşturulduğu günün ingilizce adının ilk üç harfi,
- Paketin oluşturulduğu ayın ingilizce adının ilk üç harfi,
- Paketin oluşturulduğu gün (ayın kaçıncı günü; 02 Haziran' daki gibi...),
- Paketin oluşturulduğu yıl,
- Paketleyicinin adı,
- Paketleyicinin soyadı,
- <> işaretleri arasında yer alacak şekilde paketleyicinin e-mektup adresi.
- Paketlenen uygulamanın sürüm numarası-Paketin yayın numarası.
- Üç harfli dağıtım eki (Mageia için mga, Mehmet için meh v.b.)
- Paketin üzerinde çalışacağı Mageia Linux sürümünün numarası
- Upgraded to 2.0.1
Pakette yapılan değişikliklerin her biri - işareti ile gösterilecek şekilde ayrı satırlar halinde yazılır.
Kaynak
Hazırlayan: Atilla Öntaş
