Bir RPM oluşturmak hızlı bir başlangıçtır. Kendi ellerinizle bir RPM paketi oluşturmak Kaynaklardan bir rpm paketi oluşturun

Ancak, dağıtım diskinde sağlanan rpm paketinde olmayan gerekli seçeneklerle (mysql, postgresql veya cyrus-sasl2 vb. için desteği etkinleştirin) bir paket oluşturmanız sıklıkla olur. Bu durumdan çıkış yolu kendi paketinizi oluşturmaktır.

rpm paketlerinin montajını kolaylaştırmak için, bu amaç için özel olarak tasarlanmış bir paket vardır - rpm-build.

# rpm -qi rpm-build Ad: rpm-build Yer Değiştirme: (yer değiştiremez) Sürüm: 4.3.3 Satıcı: CentOS Yayın: 7_nonptl Yapım Tarihi: 21 Şubat 2005 Pazartesi 20:21:52 Kurulum Tarihi: 9 Nisan 2005 Cmt 22: 14:57 Derleme Sunucusu: guru.build.karan.org Grup: Geliştirme/Araçlar Kaynak RPM: rpm-4.3.3-7_nonptl.src.rpm Boyut: 1576124 Lisans: GPL İmzası: DSA/SHA1, Paz 27 Şubat 2005 00: 36:59, Anahtar Kimliği a53d0bab443e1821 Paketleyici: Karanbir Singh

Açıklamadan da görülebileceği gibi, bu paket, paketleri oluşturmak için tasarlanmış bir dizi komut dosyası ve program içerir.

Herhangi bir paketi bir araya getirmek için önce sözde olanı indirmeniz gerekir. paket oluşturma kaynakları, kural olarak, bunlar src.rpm uzantılı dosyalardır. Bazen, courier-imap durumunda olduğu gibi, spec dosyası kaynaklara dahil edilir.

www.rpmfind.net rpm ve src.rpm paketlerini bulmak için çok kullanışlıdır. Örneğin, ihtiyacımız olan paketi bulduk - postfix, squid, vb. Bunu oluşturmak için hangi paketlerin gerekli olduğunu hemen bulabiliriz. İşte postix ve kalamar için standart paket bilgileri sayfası. Ayrıca, paketin bütünlüğünü kontrol etmek için bir sağlama toplamı belirtir.

Kaynakları aldıktan ve bütünlüklerini kontrol ettikten sonra uygun paketi kurmamız gerekiyor.

# rpm -ivh postfix-2.2.8-1.2.src.rpm 1:postfix ########################## # #########

Bu işlemden sonra, postfix kaynakları ve gerekli tüm yamalar ile betikler /usr/src/redhat/SOURCES/ dizinine ve spec dosyası (rpm paketi oluşturma talimatı) /usr/src/redhat/ dizinine kuruldu. ÖZELLİKLER/.

# ls /usr/src/redhat/SOURCES/ pflogsumm-1.1.0.tar.gz postfix-etc-init.d-postfix postfix-2.1.1-config.patch postfix-hostname-fqdn.patch postfix-2.1.1 -obsolete.patch postfix-büyük-fs.patch postfix-2.1.5-aliases.patch postfix-pam.conf postfix-2.2.5-cyrus.patch postfix-sasl.conf postfix-2.2.8.tar.gz README- Postfix-SASL-RedHat.txt postfix-alternatives.patch # ls /usr/src/redhat/SPECS/ postfix.spec

Bu, src.rpm yüklenirken varsayılan dosya konumudur. Prensip olarak, klasör adları kendileri için konuşur.

Paketi oluşturmaya başlamak için, spec dosyasının bulunduğu klasöre gitmeniz ve aşağıdaki komutu çalıştırmanız gerekir.

# cd /usr/src/redhat/SPECS/ # rpmbuild -ba --target=i686 postfix.spec Derleme Platformları: i686 Çalışan i686 Platformu için Oluşturma (%prep): /bin/sh -e /var/tmp/rpm - tmp.82019 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 + /bin/gzip -dc /usr/src / redhat/SOURCES/postfix-2.2.8.tar.gz + tar -xf - + STATUS=0 + "[" 0 -ne 0 "]" + cd postfix-2.2.8 ++ /usr/bin/id - u + "[" 0 = 0 "]" + /bin/chown -Rhf kökü . ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chgrp -Rhf kök . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo "Yama #1 (postfix-2.1.1-config.patch):" Yama #1 (postfix-2.1.1-config.patch): + yama -p1 -b --suffix .config -s ... ... ... Yazıldığı yer: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Yazıldığı yer: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2 .i686 .rpm Yazılan yer: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Çalışıyor(%clean): /bin/sh -e /var/tmp/rpm- tmp.73987 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + çıkış 0

Son satırlardan, biten rpm paketinin postfix-2.2.8-1.2.i686.rpm olarak adlandırıldığını ve --target belirttiğimiz için /usr/src/redhat/RPMS/i686/ klasörüne kaydedildiğini görebilirsiniz. =i686 paketi oluştururken anahtar.

Montajın kendisi herhangi bir soruna neden olmamalıdır. Peki ya kendi seçeneklerimizle bir paket oluşturmamız gerekirse, örneğin mysql veya sasl2 desteğini etkinleştirme vb. Bu amaçlar için, spec dosyasının düzeltilmesi gerekecektir.

Postfix spec dosyasının bir parçasını düşünün, postfix'in tabiri caizse standart olmayan bir spec dosyasına sahip olduğuna dikkat edilmelidir.

Örneğin MySQL destekli postfix oluşturmak istedik bunun için en başta %define MYSQL 0'ı %define MYSQL 1 olarak değiştiriyoruz ve komutu tekrar çalıştırıyoruz.

# rpmbuild -ba --target=i686 postfix.spec Yapı platformları: i686 i686 platformu için yapı hatası: Karşılanmayan yapı bağımlılıkları: postfix-2.2.8-1.2.i686 için mysql-devel gerekli

Derleme için mysql-devel paketini kurmanın gerekli olduğunu bize yazıyor. Lütfen sürümün belirtilmediğini unutmayın; bu, postfix'in desteklediği herhangi bir sürümü veya ihtiyacınız olan paketi kurabileceğiniz anlamına gelir.

Kaynaktan derliyor olsaydınız, belirli bir paketi oluşturmak için hangi paketlerin gerekli olduğunu kendiniz bulmanız gerekirdi. Bu, tar.gz veya tar.bz2 yerine src.rpm'den oluşturmanın avantajlarından biridir.

Uygun paketi kurun

# rpm -ivh MySQL-devel-4.1.9-0.i386.rpm Hazırlanıyor... ######################## # ########### 1:MySQL-devel ########################## ## #########

Ve postfix derlemesini yeniden başlatın. Bu sefer build için gerekli tüm paketlerin kurulduğunu görüyoruz ve artık sadece buildin bitmesini beklemek gerekiyor.

# rpmbuild -ba --target=i686 postfix.spec Derleme platformları: i686 i686 platformu için derleme Çalışıyor(%prep): /bin/sh -e /var/tmp/rpm-tmp.86320 + umask 022 + cd /usr / src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 ... ... ... Yazılan yer: /usr/src/redhat/SRPMS/postfix- 2.2.8-1.2.src.rpm Yazılan yer: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Yazılan yer: /usr/src/redhat/RPMS/i686/postfix- pflogsumm- 2.2.8-1.2.i686.rpm Çalışıyor(%clean): /bin/sh -e /var/tmp/rpm-tmp.52381 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix- 2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + çıkış 0

Bir araya getirdiğimiz tüm paket, şimdi onu kurmanız ve hayatın tadını çıkarmanız gerekiyor.

# rpm -ivh /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Hazırlanıyor... ################## #################### 1: sonek ##################### #################

Daha iyi bir anlayış için, daha standart bir özel dosya yapısına sahip kalamar oluşturmayı düşünün. Her zaman olduğu gibi, önce src.rpm'yi yükleyin ve boyutu ve sağlama toplamını kontrol etmeyi unutmayın.

# rpm -ivh kalamar-2.5.STABLE11-2.src.rpm 1:kalamar ########################## # #########

Olası tüm anahtarları aşağıdaki gibi bulabilirsiniz.

# cd /usr/src/redhat/SPECS # rpmbuild --bp squid.spec # cd ../BUILD/squid-2.5.STABLE11/ # ./configure --help Kullanım: configuration Seçenekler: Yapılandırma: --cache-file =DOSYA önbellek testi DOSYA'da sonuçlanır --help bu mesajı yazdır --no-create çıktı dosyaları oluşturma --sessiz, --silent `kontrol ediliyor...' mesajlarını yazdırma --site-file=DOSYA DOSYA'yı şu şekilde kullan site dosyası --version, oluşturulan autoconf sürümünü yazdır Dizin ve dosya adlarını yapılandırın: --prefix=PREFIX, mimariden bağımsız dosyaları PREFIX'e kurun --exec-prefix=EPREFIX, mimariye bağlı dosyaları EPREFIX'e kurun --bindir=DIR DIR'deki kullanıcı yürütülebilir dosyaları --sbindir=DIR sistem yöneticisi DIR'deki yürütülebilir dosyalar --libexecdir=DIR DIR'deki program yürütülebilir dosyaları --datadir=DIR DIR'deki salt okunur mimariden bağımsız veriler --sysconfdir=DIR DIR'deki salt okunur tek makine verisi DIR --sharedstatedir=DIR DIR'de değiştirilebilir mimariden bağımsız veri --localstatedir=DIR DIR'de değiştirilebilir tek makine verisi --libdir=DIR objec t kod kitaplıkları DIR'de --includedir=DIR C başlık dosyaları DIR'de --oldincludedir=DIR DIR'de gcc olmayanlar için C başlık dosyaları --infodir=DIR DIR'de bilgi dokümantasyonu --mandir=DIR DIR'de man dokümantasyonu --srcdir =DIR DIR'deki kaynakları bul --program-prefix=ÖNEK kurulu program adlarının başına ÖNEK ekle --program-suffix=SONEKİ kurulu program adlarına SONEK ekle --program-transform-name=PROGRAM sed PROGRAM'ı kurulu program adlarında çalıştır Ana Bilgisayar yazın: --build=BUILD BUILD üzerine inşa etmek için yapılandırın --host=HOST HOST için yapılandırın --target=TARGET TARGET için yapılandırın Özellikler ve paketler: --disable-FEATURE FEATURE içermez ( --enable-FEATURE= ile aynı hayır) --enable-FEATURE[=ARG] ÖZELLİK ekle --PAKETLE[=ARG] PAKET kullan --PAKETSİZ-PAKET kullanma ( --with-PACKAGE=no ile aynı) --x-includes= DIR X include dosyaları DIR'de --x-libraries=DIR X kitaplığı dosyaları DIR'de --enable ve --with seçenekleri tanındı: --disable-dependency-tracking One-ti'yi hızlandırır me builds --enable-dependency-tracking Yavaş bağımlılık ayıklayıcıları reddetme --enable-maintainer-mode enable yapma kuralları ve bağımlılıklar gündelik yükleyici için kullanışlı değil (ve bazen kafa karıştırıcı) --enable-dlmalloc[=LIB] Derle ve kullan Doug Lea tarafından yazılan malloc paketi --enable-gnuregex GNUregex'i derleyin. Bu seçeneği kullanmak için bir nedeniniz yoksa, etkinleştirmemelisiniz. Bu kitaplık dosyası genellikle yalnızca Windows'ta ve yerleşik kendi regex kitaplığına sahip olmayan çok eski Unix kutularında gereklidir. --enable-xmalloc-statistics Durum sayfasında malloc istatistiklerini göster --enable-carp CARP desteğini etkinleştir --enable-async-io[=N_THREADS] --with-aufs-threads=N_THREADS --with-pthreads için kısaltma -- enable-storeio=ufs,aufs --with-aufs-threads=N_THREADS Aufs nesne deposu için çalışan iş parçacığı sayısını ayarlayın. --with-pthreads POSIX Konularını Kullan --with-aio POSIX AIO Kullan --with-dl Dinamik bağlantı kullan --enable-storeio="modül listesi" Mağaza G/Ç modüllerinin listesi için destek oluşturun. Varsayılan, yalnızca ufs modülünü oluşturmak içindir. Kullanılabilir modüllerin listesi için src/fs'ye veya Programcı Kılavuzu bölümüne bakın.
özel mağaza modülünüzü nasıl oluşturacağınızla ilgili ayrıntılar için
--enable-heap-değiştirme
Geriye dönük uyumluluk seçeneği. lütfen
bunun yerine yeni --enable-removal-policies yönergesi.
--enable-removal-policies="politika listesi"
Kaldırma ilkeleri listesi için destek oluşturun.
Varsayılan, yalnızca lru modülünü oluşturmak içindir.
Kullanılabilir modüllerin listesi için src/repl'e bakın veya
nasıl yapılacağına ilişkin ayrıntılar için Programcılar Kılavuzu bölüm 9.9
özel politikanızı oluşturmak için
--enable-icmp ICMP pingini etkinleştir
--enable-delay-pools Bant genişliği kullanımını sınırlamak için gecikme havuzlarını etkinleştirin
--enable-useragent-log User-Agent başlığının günlüğe kaydedilmesini etkinleştir
--enable-referer-log Referer başlığının günlüğe kaydedilmesini etkinleştir
--disable-wccp Web Önbelleği Koordinasyon Protokolünü Devre Dışı Bırak
--enable-kill-ebeveyn-hack
Kapanışta ebeveyni öldür
--enable-snmp SNMP izlemeyi etkinleştir
--enable-cachemgr-hostname[=hostname]
cachemgr.cgi'yi bu ana bilgisayar için varsayılan yap
--enable-arp-acl ARP ACL listelerinin kullanımını etkinleştir (eter adresi)
--enable-htcp HTTP protokolünü etkinleştir
--enable-ssl OpenSSL kullanarak ssl ağ geçidi desteğini etkinleştirin
--with-openssl[=önek]
OpenSSL kitaplıklarıyla derleyin. yolu
OpenSSL geliştirme kitaplıkları ve başlıkları
dışında ise kurulum belirtilebilir.
sistem standart dizinleri
--enable-forw-via-db Forw/Via veritabanını etkinleştir
--enable-cache-digests Önbellek Özetlerini Kullan
bkz. http://www.squid-cache.org/FAQ/FAQ-16.html
--enable-default-err-language=lang
Hata sayfaları için varsayılan dili seçin (bkz.
hata dizini)
--enable-err-languages="lang1 lang2.."
Kurulacak dilleri seçin. (Hepsi olacak
varsayılan olarak yüklü)
--with-coss-membuf-size COSS membuf boyutu (varsayılan 1048576 bayt)
--enable-poll Select() yerine poll()'ü etkinleştirin. Normalde anket
seçime göre tercih edilir, ancak yapılandırma anketi bilir
bazı platformlarda bozulur. olduğunu düşünüyorsan
yapılandırma komut dosyasından daha akıllı, etkinleştirebilirsiniz
Bu seçenekle anket yapın.
--disable-poll poll() kullanımını devre dışı bırakın.
--disable-http-ihlalleri
Bu, bilinen kodu kaldırmanıza izin verir.
HTTP protokolü belirtimini ihlal etmek.
--enable-ipf-şeffaf
IP-Filter ağ adresi yeniden yönlendirmesini kullanma.
--enable-pf-şeffaf
Sistemler için Şeffaf Proxy desteğini etkinleştirin
PF ağ adresi yönlendirmesini kullanma.
--enable-linux-netfilter
Linux 2.4 için Şeffaf Proxy desteğini etkinleştirin.
--with-large-files Büyük dosyalar (günlükler vb.) için desteği etkinleştirin.
--enable-büyük önbellek dosyaları
Büyük önbellek dosyaları (>2GB) için desteği etkinleştirin.
UYARI: disk üzerindeki önbellek formatı bu seçenek ile değiştirilir.
--with-build-environment=model
Kullanılacak yapı ortamı. Normalde biri
POSIX_V6_ILP32_OFF32 32 bit
Büyük dosya desteği ile POSIX_V6_ILP32_OFFBIG 32 bit
POSIX_V6_LP64_OFF64 64 bit
POSIX_V6_LPBIG_OFFBIG büyük işaretçiler ve dosyalar
XBS5_ILP32_OFF32 32 bit (eski)
Büyük dosya desteği ile XBS5_ILP32_OFFBIG 32 bit
XBS5_LP64_OFF64 64 bit (eski)
XBS5_LPBIG_OFFBIG büyük işaretçiler ve dosyalar
varsayılan İşletim sisteminiz için varsayılan
--enable-leakfinder
Sızıntı Bulma kodunu etkinleştirin. Bunu tek başına etkinleştirme
hiç birşey yapmıyor; kaynağı da değiştirmelisin
kaçak bulma fonksiyonlarını kullanmak için kod. Muhtemelen
Yalnızca bilgisayar korsanları için kullanışlıdır.
--disable-ident-lookups
Bu, gerçekleştiren kodu kaldırmanıza izin verir.
Kimlik (RFC 931) aramaları.
--disable-internal-dns Bu, Squid'in doğrudan ve
DNS mesajlarını alır ve bunun yerine
eski harici "dnsserver" işlemleri.
--enable-truncate Bu, şu durumlarda unlink() yerine truncate()'i kullanır.
önbellek dosyalarını kaldırma. Kes biraz verir
performans artışı, ancak sorunlara neden olabilir
zaman uyumsuz G/Ç ile kullanıldığında. Kes daha fazlasını kullanır
bağlantıdan daha dosya sistemi düğümleri ..
--disable-hostname-kontrolleri
Squid varsayılan olarak herhangi bir ana bilgisayar adını reddeder.
adlarında uyması gereken tek karakterler
İnternet standartları. Buna katılmıyorsanız
kapatmak için bu anahtarı kullanabilirsiniz.
tarafından kullanılan çözümleyicinin
Squid bu tür host isimlerini reddetmez.. Bu
için test ortamlarına katılmaları gerekebilir.
uluslararası alan adları.
--enable-underscores Squid varsayılan olarak _ ile tüm ana bilgisayar adlarını reddeder
kendi adlarına internet standartlarına uymak.
Buna katılmıyorsanız, _ girmesine izin verebilirsiniz.
bu anahtarı kullanarak ana bilgisayar adları
Squid'in çalıştığı ana bilgisayardaki çözümleyici kitaplığı
ana bilgisayar adlarında _ öğesini reddetmez...
--enable-auth="kimlik doğrulama şeması modüllerinin listesi"
Kimlik doğrulama düzenleri listesi için destek oluşturun.
Varsayılan, Temel şema için destek oluşturmaktır.
Kullanılabilir modüllerin listesi için src/auth'a bakın veya
Programcılar Kılavuzu bölümü kimlik doğrulama şemaları
özel kimlik doğrulama düzeninizi nasıl oluşturacağınızla ilgili ayrıntılar için
modül
--enable-auth-modules="yardımcı listesi"
için geriye dönük uyumluluk takma adı
--enable-basic-auth-helpers
--enable-basic-auth-helpers="yardımcı listesi"
Bu seçenek, hangi temel şema proxy_auth'u seçer?
normalin bir parçası olarak inşa etmek ve yüklemek için yardımcılar
inşa süreci. Mevcut bir liste için
yardımcılar helpers/basic_auth dizinini görür.
--enable-ntlm-auth-helpers="yardımcı listesi"
Bu seçenek hangi proxy_auth ntlm yardımcılarını seçer
normal yapının bir parçası olarak inşa etmek ve kurmak
işlem. Kullanılabilir yardımcıların listesi için bkz.
helpers/ntlm_auth dizini.
--enable-digest-auth-helpers="yardımcı listesi"
Bu seçenek hangi özet düzeni kimlik doğrulamasını seçer
normal yapının bir parçası olarak inşa etmek ve kurmak için yardımcılar
yardımcılar/digest_auth dizini.
--enable-ntlm-fail-open Bir yardımcının başarısız olduğu durumlarda NTLM'nin arızalı açılmasını etkinleştirir
Kimlik Doğrulama adımlarından biri kalamarın
yine de kullanıcının kimliğini doğrulayın.
--enable-external-acl-helpers="yardımcı listesi"
Bu seçenek, hangi external_acl yardımcılarının kullanılacağını seçer.
normal yapının bir parçası olarak oluşturun ve kurun
işlem. Kullanılabilir yardımcıların listesi için bkz.
yardımcılar/external_acl dizini.
--with-samba-sources=/yol/to/samba-kaynak-ağacı
Doğru Samba kaynak dosyalarının bulunabileceği yol
winbind yardımcıları oluşturulurken bulundu. (varsayılan olarak
Samba-2.2.7'deki başlıkların dahili kopyalarını kullanın)

Disable-unlinkd unlinkd kullanmayın
--enable-stacktraces Önemli hatalarda otomatik arama geri izlemeyi etkinleştir
--enable-x-accelerator-değiştir
X-Accelerator-Vary desteğini etkinleştirin
HTTP başlığı. belirtmek için kullanılabilir
bir hızlandırıcı kurulumundaki varyans.
Genellikle diğer kodlarla birlikte kullanılır
isteklere özel HTTP başlıkları ekleyen.
--with-maxfd=N Maksimum dosya tanıtıcı sayısını geçersiz kıl. Kullanışlı
ayrıcalıklı olmayan başka bir kullanıcı olarak oluşturursanız
istediğiniz sayıda dosya tanıtıcı kullanmak için
sonuçta ortaya çıkan ikili destek

Gerekli anahtarı bulduktan sonra, onu %config'e ekleyin. Örneğin ssl destekli kalamar derlemek istiyoruz. Yardımdan, bunu yapmak için --enable-ssl ve --with-openssl olmak üzere iki anahtar eklemeniz gerektiğini belirledik. Uygun değişiklikleri yapıyoruz

Dosyayı kaydedin ve oluşturmaya başlayın.

# rpmbuild -ba --target=athlon squid.spec Oluşturulacak platformlar: athlon Athlon platformu için derleme Çalışıyor (%hazırlık): /bin/sh -e /var/tmp/rpm-tmp.59199 + umask 022 + cd /usr /src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf kalamar-2.5.STABLE11 + /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/squid-2.5.STABLE11.tar .bz2 ... ... ... OpenSSL etkin kullanılarak SSL ağ geçidi
OpenSSL MD5 uygulamasını kullanma ... ... ... Yazıldığı yer: /usr/src/redhat/SRPMS/squid-2.5.STABLE11-2.src.rpm Yazıldığı yer: /usr/src/redhat/RPMS/athlon/squid-2.5. STABLE11- 2.athlon.rpm Çalışıyor(%clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat/BUILD + cd squid-2.5.STABLE11 + rm - rf /var/tmp/squid-2.5.STABLE11-root + çıkış 0 Çalışıyor(--clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src /redhat /BUILD + rm -rf kalamar-2.5.STABLE11 + çıkış 0

Tüm kalamar başarıyla oluşturuldu, şimdi sadece onu yüklemek veya güncellemek için kalır.

İlk olarak, bir rpm paketi oluşturmak için sistemde ne olması gerektiğini bulalım. rpm-build paketi kurulu olmalıdır. Bu olmadan, rpmbuild komutu kullanılamaz. Bununla birlikte, montajda kullanılan bir dizi paket, bağımlılıklara göre kurulacaktır. ROSE'da bir paket oluşturmak için bağımlılıklarda bir C / C ++ derleyicisi reçete etmek genellikle alışılmış bir şey değildir, bu nedenle er ya da geç gcc ve gcc-c ++ paketlerine ihtiyacınız olacak, diğer tüm bağımlılıklar sorulmalıdır paketin kendisi için. Elbette hatalar var ve montaj sürecinde bir şeyi kaçırdığınızı anlıyorsunuz, ancak bu genellikle oldukça nadirdir ve kritik değildir.

Bir RPM paketi tam olarak nedir? RPM paketleri, kaynak paketler - src.rpm ve kuruluma hazır paketler - %(arch).rpm olmak üzere ikiye ayrılır. src.rpm paketleri, kaynak tarball'ı (program kaynağı), diğer kaynakları, yamaları ve oluşturma sürecini kontrol eden en önemli özellik dosyasını içerir. Tüm bu dosyalar bir cpio arşivinde paketlenmiştir. mc dosya yöneticisi ile src.rpm paketine girmeye çalıştığınızda göreceksiniz. Ayrıca pakette bilgi içeren bazı dosyalar var.

%(arch).rpm paketleri, kurulumdan sonra uygun dizinlere ayrıştırılacak dosyaları, bilgi dosyalarını ve kurulum komut dosyalarını içeren bir cpio arşivi içerir.

Ayrıca kaynak kodu olmadan da görüşebilirsiniz. Genellikle dağıtım kitine dahil edilemeyen tescilli programlar için oluşturulurlar (kaynak yoktur ve ikili dosyanın bir şekilde yeniden yapılması gerekir veya lisansla dağıtım aynalarına yerleştirilmesi yasaktır). Bu paketin içinde genellikle yalnızca bir spec dosyası vardır ve ikili dosya indirilir ve gerekirse paketin yüklenmesi sırasında değiştirilir (örneğin, aşağıda tartışılacak olan post komut dosyasında).

Paketleri herhangi bir kullanıcıdan toplayabilirsiniz. Bunu kök altından yapmanız önerilmez, çünkü / dizininin kurulum bölümü için kök olması ve ardından rm -rf% (buildroot) komutunun dünyadaki her şeyi yok etmesi ihtimali vardır. "çarpık" paketlerin kurulumu doğru şekilde gerçekleştirmediğini ve geçici bir dizine değil, doğrudan % (_prefix) ( / usr ) içinde bir yere yerleştirildiğini, ancak bu elbette etkilemeyecek olsa da bazı dosyalar kaybolacaktır. paketin bu makinedeki performansı.

Normal bir kullanıcı altından paket toplayabilmek için ne yapılması gerekiyor? İlk adım, ana dizininizde aşağıdaki yapıya sahip bir rpmbuild dizin dosyası oluşturmaktır:

~/rpmbuild |-- YAPI |-- KÖK YAPI |-- RPMS | |-- i586 | |-- x86_64 | `-- noarch |-- KAYNAKLAR |-- ÖZELLİKLER `-- SRPMS

BUILD , RPMS , SOURCES , SPECS , SRPMS dizinlerini manuel olarak oluşturmanız gerekir, RPMS dizininin alt dizinleri mimariye bağlı olarak derleme zamanında otomatik olarak oluşturulmalıdır.

ROS'ta paket oluşturucuyu ve satıcıyı özellik dosyalarına yazmak alışılmış bir şey değildir; bu değerler ABF yapı sistemi tarafından otomatik olarak ayarlanır. Ayrıca ABF, derlenmiş paketleri ilgili deponun anahtarıyla otomatik olarak imzalar. Bu nedenle, burada bu konulara değinmeyeceğiz.

Şimdi rpm paketinin en önemli dosyası olan spec dosyası nedir ona bakalım. Örneğin stardict paketinden alalım. Bu paket öğrenme için iyidir çünkü birkaç tarball'a sahiptir (tar ile paketlenmiş program kaynağı), birkaç paket alır ve şemalar gibi bir şeye sahiptir. Genellikle spec dosyası, paketin kendisiyle aynı ada sahiptir ( stardict.spec ). Ancak, birden çok yazılım dalını desteklemeye çalışıyorsanız kullanışlı olan bir paket sürümü ( stardict-2.spec ) ekleyebilirsiniz. Başka bir isim bile verebilirsiniz, ancak bu, en hafif tabirle, uygun değil.

Bu nedenle stardict.spec dosyasının içeriği aşağıda verilmiştir. Belirli bölümlerin hemen ardından yorumları ekleyeceğiz, ancak tüm blokları aynı dosyada birleştirirseniz, tam teşekküllü bir stardict.spec elde edeceksiniz.

Spec dosyası bölümlerden ve bir başlıktan oluşur:

Özet: StarDict sözlüğü Ad: stardict Sürüm: 2.4.8 Sürüm: 4 Lisans: GPL URL: Grup: Kullanıcı Arayüzü/Masaüstü Kaynak0: %(name)-%(version).tar.bz2 Source1: %(name)-tools- %(sürüm).tar.bz2 Yama0: %(ad)-2.4.8-desktop.patch

Özet- paketin kısa bir açıklaması, İsim- İsim, versiyon- sürüm, Serbest bırakmak- serbest bırakmak. Son üç etiket, %(name) , %(version) , %(release) makro tanımlarına karşılık gelir. Genellikle gelecekte kullanılırlar. İsim Ve versiyon genellikle tarball'ın adıyla aynıdır. Farklılarsa, prensipte sorun değil, ancak özellik dosyasının bazı yerlerinde standart olmayan yöntemlerle hareket etmeniz gerekecek. cvs, svn vs. den paket kuruyorsanız o zaman makro tanımını %define date 20070422 dosyanın en başına (tam olarak bu formatta tahmin edin neden kendiniz) yapmanız ve Release etiketini şu şekilde tanımlamanız önerilir aşağıdakiler:

Sürüm: 0.git%(tarih).4

Kaynak*- kaynak metinler, tarball'lar, sadece dosyalar. Bu örnekte, yapıyı çok daha zorlaştıran farklı programlara sahip iki tarball vardır. Konfigürasyon dosyaları gibi sıradan dosyalar, install komutu kullanılarak %%install bölümüne kolayca kopyalanabilir. Basit bir sözdizimi var -m mask_as_chmod'u yükleyin ne nerede. Bununla dizinler de oluşturabilirsiniz. Örneğimizde kullanılmadı ama man'da bununla ilgili daha fazla bilgi edinebilirsiniz.

Yama- bu paket için sizin veya bir başkasının yayınladığı yamalar, düzeltmeler. Programın kaynak kodunu değiştirmek ve ardından onu bir tarball'a sarmak alışılmış bir şey değildir. Ödeme yapmak adettendir. Bunları aşağıdaki şekilde yapabilirsiniz. Kaynak tarball'ı paketinden çıkarın, stardict-2.4.8'e sahip olacağız, ardından stardict-2.4.8'i stardict-2.4.8.orig'e kopyalayacağız. Bundan sonra, stardict-2.4.8 dizinindeki kodu değiştirin, çıkın ve diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-patch_name.patch komutunu verin. Gördüğünüz gibi yamanın isminden önce paketin %(name)-%(version) kısmı geliyor. Spesifikasyon dosyasında, yamanın adını makro tanımları olmadan yazdığınızdan emin olun. En azından sürüm, kesin. Aksi halde paket sürümünü güncellerken %(version) makrosu ile tanımlanan yama sürümünü de güncellemiş olursunuz ve yama herhangi bir değişiklik yapılmadan programın yeni sürümüne uygun olabilir. Derleme sırasında yama uygulanamadıysa, programın bu sürümü için yeniden yapılmalı veya % kurulum bölümünde devre dışı bırakılmalıdır.

Birçok dağıtımın paketlerinin özellik dosyalarında, derlemenin gerçekleştirildiği dizin olan başlıkta da BuildRoot'un tanımını bulabilirsiniz. ROSA'da bu tanıma gerek yoktur, BuildRoot adı otomatik olarak oluşturulur.

BuildRequires: libgnomeui-devel >= 2.2.0 BuildRequires: scrollkeeper BuildRequires: gettext Requires(post): GConf2 Requires(post): scrollkeeper Requires(postun): scrollkeeper

BuildRequires - programımızı oluşturmak için gerekli paketlerin virgül veya boşlukla ayrılmış olarak yazıldığı bir bölüm. Bunları bazı BENİOKU ve YÜKLE dosyalarından (bu konuda nadiren yararlı bir şey olmasına rağmen), yapılandırma sürecinden (şu anda genellikle yapılandırma komut dosyasıdır) ve oluşturma işleminin kendisinden (bazen yapılandırma bir şeyi atlar ve montaj durur).

Gereksinimler - bu bölüm kurulum sırasında bu paketin ihtiyaç duyacağı paketleri veya dosyaları(!) içerir. Oluştururken, paketimizin gerektirdiği tüm kitaplıklar otomatik olarak bağımlılıklar olarak yazılacaktır, ancak paketleri manuel olarak da belirleyebilirsiniz. Rpm ayrıca perl, python, mono ve diğerleri için bağımlılıkları otomatik olarak yazar (tüm bu bağımlılıklar elbette spec dosyasına değil, paketin kendisine yazılır). Bağımlılıkların otomatik olarak yazılmasına ihtiyacınız yoksa, özellik dosyasına yeni bir AutoReq: no etiketi eklemelisiniz. Rpm, inşa edilmekte olan programdan dahili bağımlılıklar eklediğinden, genellikle özel programlar oluşturulurken reçete edilir.

Örneğimiz, yükleme ve kaldırma komut dosyalarındaki bağımlılıklar için Requires(post) ve Requires(postun) yapılarını kullanır. Prensip olarak, basit bir Gerektirir yeterlidir. Burada yorumlanacak pek bir şey yok. Sadece StarDict'in kendisi işlem sırasında bu bağımlılıklara ihtiyaç duymaz. Yalnızca kurulum ve sökme sırasında gereklidirler.

Burada kullanılmayan birkaç yararlı etiket daha var.

Sağlar: isim1, isim2

Bu paketin yanıtlayacağı %(name) dışındaki adlar. Bu, bir paketin adını değiştirdiyseniz kullanışlıdır, ancak diğer paketler eski ada bağlı kalmaya devam eder.

Eskiler: isim1, isim2

Mevcut paketi kurarken belirtilen paketleri kaldırın. Sanki bu paketin belirtilenlerin yerini aldığını söylüyorlar (işlevsellik açısından, bir dizi dosya açısından vb.). Tasarım adını kullanabilirsiniz< . Тут вы должны сами понимать, что к чему.

Çakışmalar: ad1, ad2

Geçerli olanla çakışan paketleri listeler. Bizimkini kurmadan önce bu paketlerin manuel olarak kaldırılması gerektiği anlaşılmaktadır. Karşılaştırma işaretleri ve versiyonları olan yapılar da kullanılır (yukarıya bakın).

Öneriler: başlık1, başlık2

- yumuşak bağımlılıklar - bu pakete ek işlevler ekleyen paketler (örneğin, bir medya oynatıcı için kodekler), ancak bunlardan vazgeçilebilir.

çağ: sayı

Genellikle ya hiç gösterilmez ya da 0'a eşittir. Bu parametrenin özü budur. Stardict paketimizin bir versiyonu olsun 2.4.8 bir de daha eskisi var 2.4.5 . Öyleyse, %(epoch) stardict 2.4.5 varsa 1 2.4.8 sahipken 0 , o zaman 2.4.5 her zaman 2.4.8'den daha yeni olacaktır. Kurulum sırasında RPM'nin size söyleyeceği şey. Bu seçenek, önceki bir sürüme geri dönmek istiyorsanız kullanışlıdır (elbette, her şeyi genel bir depoya koyarsanız ve her şeyi urpmi veya rpmdrake aracılığıyla alırsanız. "Ev" ihtiyaçları için, rpm --force parametresi iş görür) . Bir Epoch etiketi tanımlanırsa: 0 , bu durumda paket, tanımlanmamış bir Epoch etiketine sahip bir pakete göre öncelikli olacaktır.

BuildArch: Mimarlık

Paketimizin altında inşa edileceği mimari. Bu seçenek belirtilmezse, paket mevcut mimari için oluşturulacaktır. Genellikle bu seçenek bir mimari paket oluşturmak için belirtilir. noarch, yani ikili dosyalar içermeyen bir paket.

ExclusiveArch: mimari1 mimari2

Bu paketin oluşturulabileceği mimariler. Genellikle modülleri çekirdeğe monte ederken kullanılır.

Bu, başlığın bittiği ve ayrı bölümlerin başladığı yerdir.

%description StarDict, GNOME ortamı için yazılmış uluslararası bir sözlüktür. "Glob-stili örüntü eşleştirme", "Seçim kelimesini tara", "Bulanık arama" gibi güçlü özelliklere sahiptir.

%(name) adına sahip olacak ana paketin açıklaması

%package araçları Özet: StarDict-Editor Gereksinim: %(name) = %(sürüm)-%(sürüm) Grup: Kullanıcı Arayüzü/Desktops

Burada adı %(name)-tools olacak yeni bir paket oluşturuyoruz. Paketi tamamen farklı bir şekilde çağırmanız gerekiyorsa, örneğin şunu yapmalısınız: %package -ntools-stardict . Yeni paketin sürümü, verilen Version etiketinden alınır. Gereksinimlere dikkat edin. Ana stardict paketine bağımlıdır. %(epoch) olsaydı, belirtmek zorunlu olurdu Gerektirir: %(ad)-%(dönem):%(sürüm)-%(sürüm). Aksi takdirde, bu paketi kuramazsınız.

%description araçları StarDict için basit bir araç.

İkinci paketin açıklaması

%hazırlık %kurulum -q -a1 %yama0 -p1

%prep bölümü montaj için hazırlığı başlatır. %setup kaynakları açar. Seçenek -Q arşivi açma çıktısını göstermez. Seçenek -a1%(SOURCE1) , ikinci tarball'ı ilk tarball'ın dizinine(!) açmak için kullanılır. Buna göre şekil SOURCE numarasını göstermektedir. Parametre ayrıca bazen kullanılır -B, ardından ikinci tarball, birincisi ile aynı dizine açılır. Buna göre, eğer bir tarball'ımız varsa, o zaman seçenekler -A, -B kullanılmaz.

Tarball'daki ilk dizininizin adı %(name)-%(version) dışındaysa, rpm bu dizine otomatik olarak giremeyecektir. Bu durumda, %setup öğesini biraz değiştirmelisiniz. stardict-2.4.8.tar.bz2 arşivindeki ilk dizinin bir adı varsa, örneğin sadece stardict ise, o zaman şöyle görünecektir:

%kurulum -q -n %(ad) -a1

Paketi açtıktan hemen sonra, %patch 'den önce gerekirse dosyaları kopyalayabilir veya kaynakları değiştirmek için herhangi bir programı çalıştırabilirsiniz. Ruslaştırma dosyasını kopyalayalım veya bazı kaynak kodlarını sed ile düzeltelim. Sadece buraya cp , sed veya her neyse deyin. Buradaki kök, ilk tarball'ın paketinden çıkarıldığı dizindir (bundan $RPM_BUILD_DIR değişkeni sorumludur, ancak çok nadiren kullanılır).

%patch yamaları uygulamak için kullanılır. Yukarıda yazdığımız gibi bir yama yaptıysanız, her zaman parametreye sahip olacaksınız. -p1. Ayrıca sıklıkla kullanılan parametredir. -b .patch_name, bir yedek oluşturmak için.

%build pushd %(name)-tools-%(version) %configure %make popd %configure %make

%build bölümü, paketin oluşturulduğu yerdir. pushd ve popd'a dikkat edin. Bu komutlarla ikinci tarball dizininde gezinip çıkıyoruz. Bu, pushd'den sonraki kök dizin olacaktır. Popd komutundan sonra ilk tarball'ın bulunduğu dizine dönüyoruz. Buna göre, bir kaynağınız varsa, bu komutları kullanmanıza gerek yoktur.

Bir pakette iki programımız olduğu için %configure konfigürasyonunu iki kez çalıştırıp iki kez make yapıyoruz. Paket, autotools kullanılarak yapılandırılmışsa, %configure makrosu, paketlenmemiş tarball'ın kökünden yapılandırma komut dosyasını çalıştırır. Genellikle birçok seçeneğe sahiptir, bunları ./configure --help ile komut satırından görebilirsiniz. %Configure'dan sonra ihtiyacınız olan seçenekleri belirleyebilirsiniz. %configure ve ./configure çağrılarının farklı olduğunu unutmayın. İlk durumda, kurulum için doğru dizinler (ve standart parametreler), ikinci - varsayılan dizinlerde yapılandırıcıya iletilecektir.

Başarılı bir yapılandırmadan sonra, bazı ek parametrelerle (özellikle çok işlemcili makinelerde paralel derleme kullanılır - seçenek) aynı adlı komutu çağıran %make makrosu derleme başlar. -J).

Paket autotools kullanmıyorsa, %configure ve belki de %make gerekmiyorsa, oluşturmak için README ve INSTALL dosyasını okuyun. ROSA'nın başka durumlar için de makroları vardır - örneğin, aynı isimli derleme aracı için %cmake.

Derleme başarıyla tamamlandığında %install bölümü devreye girer.

%install pushd %(name)-tools-%(version) %makeinstall_std popd %makeinstall_std %find_lang %(name)

%%find_lang , yerelleştirme dosyalarını arayın. Parametresi, kurulumdan sonra dizinde bulunacak dosyaların adıdır. %(buildroot)/usr/share/locale/*/LC_MESSAGES/*.mo. Genellikle %(name) ile eşleşir. Değilse, başka bir isim yazın.

Birçok özellik dosyasında, %install bölümünün en başında rm -rf %(buildroot) veya rm -rf $RPM_BUILD_ROOT ile aynı satırları içeren bir %clean bölümü görebilirsiniz. Modern ROSE'da bu gerekli değildir, bu tür temizlik otomatik olarak yapılır.

%preun %preun_uninstall_gconf_schemas %(ad)

Kurulum betikleri için bölümler. Genel olarak, birkaç tane var. %pre - yüklemeden önce çalıştırın, %post - yüklemeden sonra, %preun - kaldırmadan önce, %postun - kaldırmadan sonra. Örneğimizde, silme Gconf şemalarını kaldırır. Burada pakette sadece bir şema olduğunu ve adının paket adıyla aynı olduğunu varsayıyoruz. Şemaları kaldırmak için özel bir makro çağırdığımıza dikkat edin; bu makro, ROSA'nın rpmbuild tarafından şemayı fiilen kaldıran bir dizi gerekli Kabuk komutuna genişletilir. Paket kurulumu sırasında şemaların kurulumu, RPM dosya tetikleyicileri tarafından otomatik olarak yapılır.

Her paketin kendi komut dosyaları olabilir, bu nedenle belgeleri de okumalısınız. Düzgün çalışması için herhangi bir komut dosyası gerekmiyorsa, bu bölümler de kullanılmamalıdır. Bash betiklerini bu bölümlerde kullanabilirsiniz (tıpkı diğer bölümlerde olduğu gibi).

%files bölümünde hangi dosyaların paketlenmesi gerektiğini belirtmemiz gerekiyor. Tüm dosyalar belirtilmelidir, aksi takdirde rpmbuild sıkıştırılmamış dosyaları bildirir.

seçenek -F işlenmiş dosyaların listesini içeren bir dosya belirtilir. Bizim durumumuzda, bu dosya yerelleştirme dosyalarına giden yolları içerir. Temel olarak, kendi dosyanızı oluşturabilir ve yükleyebilirsiniz.

Dizinleri tanımlamak için özel makro tanımları kullanılır.

• %(_prefix) - /usr
• %(_sysconfdir) - /etc
• %(_bindir) - /usr/bin
• %(_datadir) - /usr/share
• %(_libdir) - sistem bitliğine bağlı olarak /usr/lib veya /usr/lib64
• %(_lib) - sırasıyla /lib veya /lib64
• %(_libexecdir) - /usr/libexec
• %(_includedir) - /usr/unclude
• %(_mandir) - /usr/share/man
• %(_sbindir) - /usr/sbin
• %(_localstatedir) - /var .
• %(systemd_libdir) - /usr/lib/systemd

%doc, dosyaları belge olarak işaretler. Üçüncü satır belirtilen dosyaları dizine kopyalar. %(_datadir)/doc/%(ad)-%(sürüm). Varsayılan olarak, rpm paketindeki dosyaların sahibi kök olacaktır ve kurulum işlemi sırasındaki izinlerle aynı izinlere sahip olacaktır. Bunun değiştirilmesi gerekiyorsa, %defattr yapısını kullanın.

%filestools %(_bindir)/stardict-editor

Stardict-tools paketi için aynı. Tools-stardict olarak adlandırılsaydı, %files şöyle görünürdü:

%files -ntools-%(ad).

Spesifikasyon dosyasındaki son şey %changelog'dur. Değişiklik günlüğünde, önceki sürüme kıyasla paketteki değişiklikleri belirtirsiniz. Sözdizimi kabaca aşağıdaki gibidir.

%changelog * 22 Nisan 2007 Paz Adınız - 2.4.8-4 - masaüstü yamasını güncelleyin

makro tanımları

Şimdi makrolara ve değişkenlere daha yakından bakma zamanı. Diyelim ki SVN'den bir paket oluşturuyoruz, bu durumda revizyon tarihi genellikle sürümde yer alır. Spec dosyasının en başında, tarih değişkenini tanımlamanız gerekir:

%tarihi tanımla 20070612

Gördüğümüz gibi, %define makrosu değişkenleri tanımlamaktan sorumludur. Şimdi, spec dosyasının herhangi bir yerinde, değişkenimizi %(date) biçiminde kullanabiliriz (parantezler gerekli değildir, ancak ROS'ta değişkenleri parantez içinde almak alışılmış bir durumdur ve makro tanımları almaz; ayırt etmek daha kolaydır onların arasında). Örneğin, temel parametrelerin tanımlanması şuna benzer:

Versiyon: 0.5 Yayın: 0.svn%(date).3

Tarihten önce geldiğini unutmayın 0. ve tarihten sonra - sürümü yükseltmek gerekirse artan bir sayı. Bu neden yapılır? Nihai sürüm nihayet yayınlandığında (bizim durumumuzda - 0.5 ), revizyon kaldırılabilir ve sürümde yazmak kolaydır 1 . Aynı zamanda kelimenin tam anlamıyla 1 ile başlayan herhangi bir satırdan daha büyük 0 ve paket, SVN revizyonlarından oluşturulan ön paketlerden daha yeni kabul edilecektir.

Çok popüler bir makro tanım, yapıdır.

%if koşul action1 %else action2 %endif

veya %else olmadan sadece %if. İşin özü basit, eğer %if koşulu doğruysa action1 gerçekleştirilir, aksi takdirde action2 gerçekleştirilir.

Diyelim ki yine SVN'den bir şeyler topladık. Genellikle arşivin içinde, eğer SVN'den geliyorsa, %(name)-%(sürüm) dizini yerine sadece %(name) belirtirler (sim-0.9.5.tar.bz2 arşivinin içinde bir sim dizini vardır, çünkü sim 0.9.5'in son sürümü mevcut değil, ancak son sürümün ilk dizini sim-0.9.5 olacak). Spec dosyasını her seferinde yeniden yazmamak için aşağıdaki makro tanımlarını yapabilirsiniz:

%define svn 1 ... %prep %if %(svn) %setup -q -n %(name) %else %setup -q %endif

svn değişkeni tanımlı değilse, betiğin %else'den sonraki kısmı çalıştırılacaktır. Daha katı bir koşul da kullanabilirsiniz (alıntıları unutmayın):

%define svn 1 ... %prep %if "%(svn)" == "1" %setup -q -n %(name) %else %setup -q %endif

Spec dosyasının tüm bölümlerinde, herhangi bir "zil ve ıslık" olmadan herhangi bir Linux komutunu kullanabiliriz, ancak dosya başlığında bu o kadar basit değildir. Örneğin bir paket için (epiphany diyelim) firefox versiyonunu belirleyip Requires: kısmına koymamız gerekiyor. Bunun gibi görünecek:

Gerektirir: firefox = %(rpm -q firefox --qf "%%(sürüm)")

Lütfen harici komutun %() içinde yürütüldüğünü (bash - $() 'daki gibi) ve özellik dosyasında parametrelere iki % işareti koymanız gerektiğini unutmayın. Bu şekilde, örneğin çekirdek sürümünü belirlemek için herhangi bir Linux komutunu çağırabilirsiniz.

Diğer bir popüler makro, %ifarch .. %endif yapısıdır. Mimari, %ifarch'tan sonra belirtilenle eşleşirse, bazı işlemler gerçekleştirilir. i386, i486, i586, i686, i?86, x86_64 mimarileri ve tabii ki muhtemelen karşılaşmayacağınız başka mimariler var.

Yukarıda spec dosyasının tüm bölümlerinde belirtildiği gibi, for, while, if, vb. dahil olmak üzere herhangi bir Shell komutunu kullanabilirsiniz.

paket oluşturma

Şimdi doğrudan paketin montajına geçelim. Kaynaklar ve yamalar SOURCES dizininde ve spec dosyası SPECS dizininde olmalıdır. Bundan sonra, komutu vermeniz gerekir:

Rpmbuild -ba özellik dosyası

Bundan sonra, paket inşa edilecek (veya inşa edilmeyecek, ancak hatalarla düşecek) ve ikili paketler RPMS dizininin alt dizinlerinde görünecek ve kaynak kodu SRPMS dizininde görünecektir.

Çoğu zaman, derleme tamamlanmadan hemen önce rpmbuild, bulunan ancak paketlenmemiş dosyalar hakkında bir mesaj verir. Bu, onları %files bölümünde listelemediğiniz anlamına gelir. Onları oraya eklemeniz yeterli. Bu dosyaların pakete dahil edilmesini istemiyorsanız, aşağıdaki yöntemlerden birini kullanabilirsiniz:

• %files bölümüne bir makro ekleyin

• Spesifikasyon dosyasının başına bir makro tanımı ekleyin

Yalnızca ikiliyi veya yalnızca kaynağı oluşturmanız gerekiyorsa, bunun yerine -ba kullanılmalıdır -bb Ve -bs sırasıyla. Yararlı rpmbuild parametrelerinden biri not edilebilir -temiz(tüm çöpleri kaldır) -rmsource(KAYNAK dizininden kaynakları kaldırın) ve -hedef=mimari(belirli bir mimari için bir paket oluşturun).

Yalnızca belirli bir bölümde komut dosyalarını çalıştırmak da mümkündür. Bu tür parametreleri burada açıklamayacağız, bkz. rpm oluşturma.

Halihazırda sistemde yüklü olan bir RPM paketinden bir RPM paketi oluşturma

Bazen bazı paketler sistemde zaten kuruludur (belki çok eski bir sistemde) ve gerçekten onunla bir rpm almak istersiniz, ancak kaydedilmemiştir. İhtiyaçlarınıza uyacak şekilde değiştirilmiş yapılandırma dosyalarıyla hızlı bir şekilde bir paket oluşturmak da isteyebilirsiniz.

Bu sorunu çözmek için rpmrebuild yardımcı programını kullanmalısınız. Bu bash yardımcı programı, ROSA katkı deposunda mevcuttur.

Onunla çalışmak son derece kolay. Tek yapmanız gereken şu komutu vermek:

Rpmrebuild kurulu_paket_adı

Herhangi bir dosya değiştiyse, bu konuda size bilgi verilir, ancak oluşturma işlemi kesintiye uğramaz.

Rpmrebuild çok sayıda seçeneğe sahiptir, örneğin paketin sürümünü, değişiklik günlüğünü, betikleri, Gerekli bölümleri, paket açıklamalarını ve daha fazlasını değiştirebilirsiniz. Komut dosyasının kendi kendine oluşturacağı özellik dosyasını bile değiştirebilirsiniz. Biraz korkutucu olacak ama yine de hiç yoktan iyidir.

Tüm parametreler kullanılarak görüntülenebilir

Rpmrebuild --yardım

İnternette bulduğum tüm kılavuzlar çoğu durumda iki türe ayrılır:
- belgelerin çevirisi (makalem gelecekte ihtiyaç duyacağınız bilgilerin yalnızca bir kısmını kapsadığı için okumanızı tavsiye ediyorum)
- zaten her şeye sahip olduğumuzda rpmbuild'i nasıl çalıştıracağımıza dair kısa talimatlar.
Şahsen, hiçbir şeyin olmadığı kaynaktan bir paket ve en önemlisi paketin oluşturulması gereken bir özellik dosyası oluşturma ihtiyacı ile karşı karşıya kaldım. Sonuç olarak, paketi oluşturmak için kendi spec dosyamızı yazacağız ve kendi yapılandırmalarımızı oraya hemen ekleyeceğiz (bu soru da pek kutsal değil).

Daha önce . Paket yöneticisi kullanan bir dağıtımda uygulamaların onun üzerinden yüklenmesi taraftarıyım, dolayısıyla CentOS'ta yazılımları kaynaktan derlemeyi sevmiyorum. Bu nedenle her şeyi kendim için paketler halinde toplamaya karar verdim. Gerekli olan topal (özellik dosyalarıyla birlikte gelir) ve x264'ü (bu makaleyi okuduktan sonra kendiniz için bir özellik dosyası yazabilirsiniz) derlemek, gelecekte size herhangi bir sorun çıkarmamalıdır.

Ve bu yüzden, önce paketi kuracağımız "ortamı" kurmamız gerekiyor. Kök altından paket oluşturmanız önerilmez, bu nedenle ayrı bir kullanıcı oluşturacağız, ancak şimdilik gerekli tüm yazılımları kuracağız:

Yum install gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools

ve şimdi özel bir kullanıcı bulalım

kullanıcı ekleme rpmbuild

ve altına gir

Su - rpmbuild

komutu yürüt

Rpmdev-setuptree

böylece oluşturmamız için gerekli dizin yapısını genişletiyor
Ve şimdi doğrudan montaja geçebiliriz.
aslına ihtiyacımız var

Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2

aç onu

Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2

Yanında içeriği olan bir yapılandırma dosyası koyalım:

Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg şifre = subtitles.encoding = utf-8 subtitles.font = Verdana klasörleri = Filmler:/home/share/films

Sunucu dosyasını buradan indirin:

Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar

Ve başlatma betiği:

Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #açıklama: AirVideo sunucusu # Kaynak işlev kitaplığı. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo case "$1" başlangıçta) echo -n "AirVideo sunucusu başlatılıyor: " daemon java -jar $(PREFIX_DIR)/AirVideoServerLinux.jar $( PREFIX_DIR)/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && başarı || hata yankısı;; durdur) echo -n "AirVideo sunucusu durduruluyor: " killproc java echo ;; durum) durum java ;; yeniden başlat | yeniden yükle) $0 durdur ; 0 $ başlangıç;; *) echo "Kullanım: airvideo (başlat|durdur|durum|yeniden yükle|yeniden başlat" çıkış 1 ;; esac

Artık montaj için spec dosyamızı yazmaya geçebiliriz.
Öncelikle farklı başlıklarımız var. Paket adı, sürümü ve sürümü önemlidir, derlemeden önce kaynak kodun hangi dizine konuşlandırılacağını belirlerler. Source1 , Source2 ve Source3'te, oluştururken pakete eklenmesi gereken 3 ek dosyamızı, config, server ve init betiğini belirtiyoruz.

Ad: ffmpeg Sürüm: 2.4.5 Sürüm: beta7 Özet: AirVideoServer Lisansı için ffmpeg: GPL URL: http://inmethod.com/airvideo/ Kaynak: http://inmethod.com/airvideo/download/ffmpeg-for-2.4 .5-beta7.tar.bz2 Kaynak1: airvideoserver.conf Kaynak2: AirVideoServer Source3: AirVideoServerLinux.jar BuildRoot: %(_tmppath)/%(ad)-for-%(sürüm)-%(sürüm)

%description AirVideoServer için H264/AVC video akışlarını kodlamak için yardımcı program ve kitaplık.

%prep bölümü, derlemeyi başlatmak için gerekli komutlardan sorumludur, böylece dizini - biçiminde yeniden adlandırmak zorunda kalmam, paketlenmemiş kaynakların nerede olduğunu belirtmek için sadece -n tuşunu kullanırım

%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/

%build bölümü, kaynağın doğrudan oluşturulmasından sorumludur, anahtarları, normal bir derleme ve kaynaklardan kurulumda olduğu gibi ihtiyacınız olanlarla değiştirebilirsiniz:

%build ./configure \ --prefix="%(_prefix)" \ --bindir="%(_bindir)" \ --libdir="%(_libdir)" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame

% install bölümü, paket dosyalarını sisteme kurmak için komutlar içerir, burada ek olarak config dosyamızı, sunucumuzu ve init betiğimizi nereye kuracağımızı belirtmemiz gerekir.

%install %(__rm) -rf %(buildroot) %(__make) install DESTDIR="%(buildroot)" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE1) $RPM_BUILD_ROOT/usr/local/AirVideo/ kurulum -m 644

Çöp kutusunu temizleyin ve ldconfig'i çalıştırın

%clean %(__rm) -rf %(buildroot) %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

%files bölümündeki komutlar, uygun özniteliklerle yapı ağacından rpm paketine kopyalanması ve ardından bu paket kurulduğunda hedef sisteme kopyalanması gereken dosya ve dizin listelerini belirtir.

%files %defattr(-,root,root,-) %doc KOPYALAMA* KREDİLER BENİOKU* %(_bindir)/avconv %(_bindir)/avprobe %(_bindir)/avserver %(_bindir)/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar

%doc makrosu belge dosyalarını, telif haklarını ve diğer şeyleri işaretler.
Bunun üzerine spec dosyamız hazır artık derlemeyi kendisi çalıştırmamız gerekiyor.

Rpmbuild -bb ffmpeg/ffmpeg.spec

Paketin başarıyla derlenmesinin ardından, tamamlandıktan sonra, RPMS/_architecture_/ dizininde, artık herhangi bir makineye yüklenebilen ve konuşlandırılabilen ffmpeg-2.4.5-beta7.x86_64.rpm paketimiz olacak.

Umarım bu küçük öğretici, daha sonra hayatınızı kolaylaştıracak kendi yapılandırma dosyalarınızla kendi kurulum paketlerinizi oluşturmanıza yardımcı olur.

Projelerimizin çoğu açık kaynaklı kütüphaneler kullanıyor. Belirli bir platform için geliştirme yaparken, projeye her yeni geliştirici katıldığında aynı kitaplıkları kaynaktan oluşturmak mantıklı değildir. Ayrıca, sistemi RPM veritabanında listelenmeyen "artık" dosyalarla doldurduğu için, la make && sudo make install kitaplıklarının yüklenmesi kötü bir davranış olarak kabul edilir.

Çözüm olarak, derlenmiş kitaplıklardan RPM paketlerinin toplanması ve tüm geliştiricilerin kullanabileceği tek bir depoda saklanması önerilmiştir. Aşağıda, paketler oluşturmak için talimatlar ve bazı ipuçları bulunmaktadır.

Talimatlar Red Hat Enterprise Linux 6 örneğini temel alacaktır, ancak küçük değişikliklerle diğer dağıtımlara uyarlanabilir. Örneğin, zeromq kütüphanesinden bir paket oluşturacağız.

Bir paket oluşturmadan önce

İnşa etmeden önce yapmanız gereken ilk şey, ihtiyacınız olan paketin sizden önce başka biri tarafından inşa edilmediğinden emin olmaktır. Genellikle rpmfind.net ve rpm.pbone.net gibi kaynaklar ihtiyacınız olanı bulacaktır. Ancak kitaplığın gerekli sürümü bulunamadıysa veya platformunuz için derleme yoksa paketi kendiniz oluşturmanız gerekir.

rpmbuild

Paketler yardımcı program kullanılarak birleştirilir rpmbuild. Kullanmadan önce yapı ortamını yapılandırmanız gerekir. Örneğin, ~/rpmbuild dizininde gerekli dizin ağacını oluşturalım:

$ mkdir ~/rpmbuild $ mkdir ~/rpmbuild/(BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS)

Oluşturulan dizin ağacının nerede olduğunu bilmesi için rpmbuild yardımcı programı için bir yapılandırma dosyası oluşturuyoruz:

$ echo "%_topdir %(echo $HOME)/rpmbuild" >~/.rpmmakrolar

rpmbuild başlangıçta ~/rpmbuild/BUILDROOT/ dizinindeki paket dosyalarını arayacaktır.<имя_пакета>. Zeromq örneğini kullanarak RPM paketlerinin nasıl adlandırıldığını bulalım:

sıfırmq-3.2.4-1.rhel6.x86_64.rpm

• zeromq - aslında, paketlenmiş yazılımın adı;
• 3.2.4 - yazılım versiyonu;
• 1.rhel6 - paket oluşturma numarası (sürüm numarası) - bu yazılım sürümünün bir rpm paketine kaç kez yerleştirildiği. rhel6 veya el6 soneki genellikle Red Hat Enterprise Linux 6 paketlerine atanır;
• x86_64 - yazılımın derlendiği işlemci mimarisi.

Paket adının alanlarını ayıran karakterlere dikkat edin. Tam olarak örnekteki ile aynı olmalıdırlar.

BUILDROOT'ta zeromq için bir dizin oluşturuyoruz:

$ mkdir ~/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64

kütüphaneyi inşa etmek

Elbette, ikili paketi oluşturmadan önce kitaplığın kendisini derlemeniz gerekir. Kütüphane GNU Autotools derleme sistemini kullanıyorsa, bu genellikle şu komutlarla yapılır:

$ ./yapılandır $ yap

Şimdi kütüphaneyi BUILDROOT'ta oluşturduğumuz dizine kurun:

$ make install DESTDIR="$HOME/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64"

DESTDIR parametresi, makefile'lerde her zaman işlenmez. Örneğin, qmake, bu seçeneği yok sayan makefiles üretir. Kitaplık, GNU Autotools dışında bir yapı sistemi kullanıyorsa, kitaplığı belirtilen dizine kurmak için oluştururken hangi seçenekleri geçmeniz gerektiğiyle ilgili ilgili kılavuzu okuyun.

paketi oluşturmak için spec dosyası

RPM paketleri, arşivlenmiş dosya ağacına ek olarak paketle ilgili meta bilgileri depolar. Oluştururken, ~/rpmbuild/SPECS klasöründe bulunan spec dosyasında belirtilmelidir. Zeromq kitaplığı için bir zmq.spec dosyası örneğini ele alalım:

Ad: zeromq Sürüm: 3.2.4 Sürüm: 1.rhel6 Özet: Hızlı, mesaj tabanlı uygulamalar için yazılım kitaplığı Paketleyici: Kuruluşum Grup: Sistem Ortamı/kütüphaneleri Lisans: LGPLv3+ istisnalarla %description 0MQ hafif mesajlaşma çekirdeği, geleneksel olarak özel mesajlaşma ara katman yazılımı ürünleri tarafından sağlanan özelliklerle standart yuva arabirimlerini genişletir. 0MQ soketleri, eşzamansız mesaj sıralarının, çoklu mesajlaşma kalıplarının, mesaj filtrelemenin (abonelikler), çoklu taşıma protokollerine kesintisiz erişimin ve daha fazlasının soyutlanmasını sağlar. Bu paket, 3.x sürümleri için ZeroMQ paylaşılan kitaplığını içerir. %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-,root,root) /usr/lib64/libzmq.so.3 /usr/lib64/libzmq.so.3.0.0 %paket geliştirme Özeti: Zeromq3 için geliştirme dosyaları Grup: Geliştirme/Kütüphaneler Gereksinim: %(ad) = %(sürüm)-%(sürüm) %description devel Zeromq3-devel paketi, zeromq3 3.x kullanan uygulamaları geliştirmek için kitaplıklar ve başlık dosyaları içerir. %files devel %defattr(-,root,root) /usr/include /usr/share /usr/lib64/pkgconfig /usr/lib64/libzmq.so /usr/lib64/libzmq.a /usr/lib64/libzmq.la

Dosyanın başında, paket hakkında bilgi içeren minimum alan kümesi belirtilir. İlk üç alanın değerlerinden ( İsim, versiyon, Serbest bırakmak) paket adını oluşturur, bu nedenle burada doğru değerlerin belirtilmesi önemlidir. Değerler, oluşturulmakta olan paketin dosya ağacı ile dizinin adı ile eşleşmezse, rpmbuild bir hata üretecektir. Alan Lisans ayrıca gereklidir - onsuz, rpmbuild paketi oluşturmayı reddedecektir.

Bölüm ataması %Tanım açıkça. Bölümler %postalamak Ve %postun sırasıyla paket dosyaları sisteme yüklendikten sonra ve paket dosyaları sistemden kaldırıldıktan sonra yürütülen komut dosyalarını içerir. Bu, paket dinamik kitaplıkları (.so) standart olmayan dizinlere kurarsa (yani /lib, /usr/lib, /lib64 veya /usr/lib64'te değil) kullanışlıdır. Bu durumda paket, ldconfig için bir yapılandırma dosyası sağlamalı ve onu /etc/ld.so.conf.d içine kurmalıdır. Takım ldconfig dinamik yükleyici önbelleğini, yapılandırma dosyalarında belirtilen dizinlerde bulunan tüm kitaplıklarla günceller.

Kısımda %Dosyalar rpm'de paketlenmiş dosyaların bir listesini belirtir. Direktif %defattrşu biçimde varsayılan dosya özniteliklerini belirtir:

%defattr(, , ,