-Dbg, -dev, -doc paketleri nasıl ve neden oluşturulur?


15

Bir paket için bir Ubuntu paketi yazıyorum, bu da daha sonra başka yazılımlar oluşturmak için kullanılan bir dizi kitaplık ve başlık sağlıyor. Paket ayrıca birbirine bağımlı küçük alt paketler halinde parçalanır; bu anlamda paket güçlendirmeye oldukça benzer.

Boost gibi paketlerin

[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]

ama ismiyle geçen hiçbir şey boostveya libboost.

  • Bunun arkasındaki fikir nedir?
  • Amaçları nelerdir -dbg, -devve -docpaketler?
  • Bu paketler için derleme dosyalarının nasıl yazılacağına dair herhangi bir talimat var mı?

Yanıtlar:


13

Fikir ve Amaç

Bu farklı paketleri ayırmanın ana nedeni disk alanı ve indirme hızı ile ilgilidir. Özellikle, ayna alanı için büyük bir endişe kaynağıdır çünkü verinin birden fazla kopyasının dağıtılması anlamına gelir. Yaparak foo-common, foo-dataya da foo-docpaketleri Architecture: all, sadece bir arşivde verilerin kopyasını yerine her mimarisi ile kopyalanan ettikten tutmak (örn i386, amd64, vb ...). Hata ayıklama sembolleri çoğu kullanıcı için gerekli değildir ve paket indirmenin daha uzun sürmesini sağlar.

Resmi Ubuntu arşivlerindeki -dbgpaketler için, paketleri manuel olarak oluşturmak için hiçbir neden yoktur . Derleme makineleri, hata ayıklama sembollerini otomatik olarak çıkarır ve -dbgsymddebs.ubuntu.com'da barındırılan paketlere yerleştirir. (Bkz: Sembol Paketlerinde Hata Ayıklama ) -dbgpaketleri genellikle Debian'dan taşınır.

Talimatlar

Uygulamaya gelince, şu soruya bir göz atın:

Kısaca, debian/controlher paket için yeni stanzalar oluşturulmalıdır . Sonra debian/foo-*.installdosyaların da oluşturulması gerekir. Bu dh_install, doğru içerikleri doğru paketlere yerleştirmenize izin verecektir .

foo.installGibi görünebilir ana ikili paket için:

usr/bin/
usr/lib/

foo-common.install, foo-data.install, foo-doc.install, Ya da her neyse:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

Ve için foo-dev:

/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so

foo-dbgPaketi oluşturmak debian/rulesnormalde olduğu gibi düzenleme gerektirir dh_strip, hata ayıklama sembollerini çıkarır. Bu yüzden bu davranışı geçersiz kılmalıyız:

.PHONY: override_dh_strip
override_dh_strip:
        dh_strip --dbg-package=foo-dbg

12

Boost karmaşık bir örnektir, önce daha basit olana bakalım.

Kesin olarak, openssl kaynak paketine 5 ikili paketler sunar:

  • libssl1.0.0OpenSSL dinamik kitaplığını içerir, sürüm 1.0.0. Bu kütüphaneye bağlı programların çalıştırılması gereken budur. 1.0.0 ile ikili olarak uyumlu olmayan başka bir sürüme bağlı başka programlarınız varsa, paket adı bir sürüm numarası içerir, çünkü aynı anda kütüphanenin başka sürümleri de yüklü olabilir.
  • opensslOpenSSL kitaplığını kullanan komut satırı araçları içerir. Kitaplığın birden çok sürümüne sahip olsanız bile, bu araçların birden çok sürümüne ihtiyacınız yoktur: yalnızca bir tane /usr/bin/opensslve ilişkili araçlar, veriler ve belgeler vardır.
  • libssl-devOpenSSL'ye bağlanan bir programı derlemek istiyorsanız, ihtiyacınız olan dosyaları içerir. C başlık dosyaları ( *.h), bağlantı kütüphaneleri ( *.a, *.so) ve çeşitli dosyalar vardır.
  • libssl-docOpenSSL kütüphanesi için belgeler içerir. Bu pakete yalnızca kütüphaneyi kullanan programlar yazacaksanız ihtiyacınız olacaktır.
  • libssl1.0.0-dbghata ayıklama simgeleri içerir. Yalnızca OpenSSL kitaplığında veya onu kullanan programlarda hata ayıklayan kişiler için yararlıdır. andrewsomething yanıtı bu -dbgpaketler hakkında daha fazla bilgi var .

Buna ek olarak, hassas, kütüphanenin eski bir sürümünü içerir libssl0.9.8, çünkü hala eski sürüme bağlı programlar vardır.

Görebileceğiniz diğer paketler C dışındaki diller için ciltlemelerdir. OpenSSL herhangi biriyle birlikte gelmez (diğer diller için OpenSSL'de ciltler vardır, ancak aynı kaynaktan gelmezler). Bir örnek Sqlite3 ile, gemiler TCL ciltleri .

Bunun gibi paketleri bölmenin temel nedeni, farklı paketlerin farklı hedef kitlelere sahip olmasıdır. Hiç kimsenin bir şey derlemediği bir sistem sadece çekirdek libpakete ve belki de komut satırı araçlarına ihtiyaç duyar ; gerekirse otomatik olarak bağımlılıklardan yüklenir. Birisi kütüphaneyi kullanan bir programı derlemek istiyorsa, -devpakete ihtiyacı vardır . Birisi kütüphaneyi kullanan bir program yazmak istiyorsa, -docpakete ihtiyacı vardır .

Peki Boost ne olacak? Aynı yapıyı takip eder, ancak Boost büyük bir kütüphane olduğundan, daha küçük paketlere ayrılır: libboost-*1.46.1ve libboost-*1.46-dev. Kesin olarak, orada Boost, yalnızca bir sürümü olan 1.46 ama oneiric de vardı 1,42 ve 1,46 . Ayrıca, sürüm paketini bağımlılık olarak çeken bir meta paket yükseltme-varsayılanları da vardır.

Libhangul'a baktığımızda , dinamik kütüphane paketine libhangul1ve geliştirme paketine ek olarak libhangul-devbir paket var libhangul-data. Bu paket, kitaplık için gereken ek verileri içerir. Kütüphanenin birden fazla sürümüne sahip olsanız bile, -datapaketi paylaşabilirler . Ayrıca, paket mimariden bağımsızdır. Çok sayıda mimariden bağımsız veri içeren yazılım, dağıtım sitelerinde yer kazanmak için mimariye bağımlı ve mimariden bağımsız paketlere ayrılır. Benzer bir anlama sahip başka bir sonek -common.

Ubuntu ve Debian paketleme kuralları çok benzerdir, bu nedenle Debian paketlerinin yapılmasıyla ilgili materyaller Ubuntu için de geçerlidir. Aslında, Debian ve Ubuntu için aynı kaynak pakete sahip olabilirsiniz; Debian ve Ubuntu paketlerini farklı kılan tek şey, bunları farklı kütüphane sürümlerine karşı derlemektir ve bu, Ubuntu'nun farklı sürümleri arasındaki farktan başka bir şey değildir. Var Debian geliştirici belgeleri el altında, özellikle Debian Politikası Manuel ve Geliştirici Başvurusu ; giriş için Yeni Bakım Kılavuzu'na bakınız . Debian projesi ile çalışma ile ilgili parçaları görmezden gelin ve bir paket hazırlama ile ilgili bölümleri okuyun.dh_make bir deb paketini kullanmaya başlamak için iyi bir yoldur (“Kütüphane” yi seçmek istersiniz).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.