5.2. Informasi-Meta Paket

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.

5.2.1. Penjelasan: Berkas `control`

Berkas ini menggunakan struktur yang mirip dengan header surel (sebagaimana didefinisikan oleh RFC 2822) dan sepenuhnya dijelaskan dalam Kebijakan Debian dan halaman manual deb-control(5) dan deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

Contohnya, untuk apt, berkas control nampak sebagai berikut:

$ apt-cache show apt
Package: apt
Version: 2.2.4
Installed-Size: 4337
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 2.2.4)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)
Description-en: commandline package manager
 This package provides commandline tools for searching and
 managing as well as querying information about packages
 as a low-level access to all features of the libapt-pkg library.
 .
 These include:
  * apt-get for retrieval of packages and information about them
    from authenticated sources and for installation, upgrade and
    removal of packages together with their dependencies
  * apt-cache for querying available information about installed
    as well as installable packages
  * apt-cdrom to use removable media as a source for packages
  * apt-config as an interface to the configuration settings
  * apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
 hardware::storage:cd, implemented-in::c++, implemented-in::perl,
 implemented-in::ruby, interface::commandline, network::client,
 protocol::ftp, protocol::http, protocol::ipv6, role::program,
 scope::application, scope::utility, suite::debian, use::downloading,
 use::organizing, use::playing, use::searching, works-with-format::html,
 works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_2.2.4_amd64.deb
Size: 1491328
MD5sum: 24d53e8dd75095640a167f40476c0442
SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Let us have a closer look at the purpose of some of the fields listed by the previous command.

KEMBALI KE DASAR RFC — Internet standards

RFC ialah singkatan dari “Request For Comments”. Sebuah RFC umumnya ialah dokumen teknis yang menjelasan apa yang akan menjadi standar Internet. Sebelum menjadi terstandar dan dibekukan, standar ini dikirim untuk ditinjau oleh umum (karenanya nama mereka demikian). IETF (Internet Engineering Task Force) memutuskan evolusi status dari dokumen tersebut (standar yang diusulkan, draf standar, atau standar).

RFC 2026 menjelaskan proses standarisasi protokol Internet.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Ketergantungan: Field `Depends`

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:

<<: kurang dari;
<=: kurang atau sama dengan;
=: sama dengan (catat bahwa “2.6.1” tidak sama dengan “2.6.1-1”);
>=: lebih dari atau sama dengan;
>>: lebih dari.

In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.

DEBIAN POLICY field Rekomendasi, Saran, dan Peningkatan

Field Rekomendasi dan Saran menjelaskan ketergantungan yang tidak wajib. Ketergantungan “direkomendasikan”, paling penting, sangat meningkatkan fungsionalitas yang ditawarkan oleh paket namun tak terlalu diperlukan oleh operasinya. Ketergantungan “disarankan”, lebih penting, menunjukkan bahwa beberapa paket mungkin melengkapi dan meningkatkan utilitasnya, namun sangat beralasan untuk menginstallnya tanpa yang lain.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them (the package description or its documentation may contain information which extra functionality they will activate). The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

Field Enhances juga menjelaskan sebuah saran, namun dalam konteks yang berbeda. Sebenarnya berada di paket yang disarankan, dan bukan dalam paket yang memperoleh keuntungan dari saran. Menariknya terletak pada bahwa adalah mungkin untuk menambahkan saran tanpa perlu memodifikasi paket yang diperhatikan. Dengan demikian, semua add-on, plugin, dan ekstensi lain dari sebuah program dapat muncul pada daftar saran yang berhubungan dengan perangkat lunak. Meskipun hal ini telah ada selama beberapa tahun, field terakhir ini umumnya diabaikan oleh program seperti apt-get atau synaptic. Tujuannya ialah untuk saran yang dibuat oleh field Enhances untuk menampilkan saran tradisional kepada pengguna — ditemukan di field Suggest.

DEBIAN POLICY Pre-Depends, lebih mendesak Depends

“Pre-dependencies”, yang terdaftar di field “Pre-Depends” di header paket, melengkapi ketergantungan normal; syntaxnya mirip. Ketergantungan normal dimaksudkan paket yang diperlukan harus dibongkar dan dikonfigurasi sebelum konfigurasi paket menjelaskan ketergantungan. Sebuah pre-dependency menetapkan bahwa paket yang diperlukan harus dibongkar dan dikonfigurasi sebelum eksekusi skrip pre-instalation paket menjelaskan pre-dependency, sebelum instalasinya.

A pre-dependency is very demanding for apt, because it adds a strict constraint on the ordering of the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It is even recommended to consult other developers on debian-devel@lists.debian.org before adding a pre-dependency. It is generally possible to find another solution as a workaround.

5.2.1.2. Konflik: field `Konflik`

Field Konflik menandakan ketika paket tidak dapat diinstall secara simultan dengan paket lain. Alasan yang paling umum untuk hal ini ialah kedua paket menyertakan berkas dengan nama dan path yang sama, atau menyediakan layanan yang sama pada port TCP yang sama, atau akan menghalangi operasi satu sama lain.

dpkg akan menolak memasang paket jika menimbulkan konflik dengan paket yang telah terpasang, kecuali paket yang baru menetapkan akan "menggantikan" paket terpasang, yang dalam kasus tersebut dpkg akan memilih untuk mengganti paket lama dengan yang baru. apt selalu mengikuti instruksi Anda: jika Anda memilih untuk memasang paket baru, akan secara otomatis menawarkan untuk membongkar paket yang menimbulkan masalah.

5.2.1.3. Ketidakcocokan: Field `Break`

Field Break (rusak) memiliki efek yang mirip dengan field Konflik, namun memiliki makna khusus. Ini menandakan bahwa instalasi paket akan “merusak” paket lain (atau beberapa versinya). Secara umum, ketidakcocokan antara kedua paket ini bersifat fana, dan hubungan Break secara khusus mengacu pada ketidakcocokan versi.

dpkg akan menolak memasang paket yang merusak paket terpasang, dan apt akan mencoba menyelesaikan masalahnya dengan memutakhirkan paket yang akan rusak dengan versi yang lebih baru (yang diasumsikan diperbaiki dan, sehingga, cocok kembali).

Situasi semacam ini mungkin terjadi ketika pembaruan tanpa kompabilitas ke belakang: hal ini terjadi jika versi baru tidak lagi dapat berfungsi dengan versi lama, dan menimbulkan tidak berfungsi di program lain tanpa membuat ketentuan khusus. Field Breaks menghalangi pengguna untuk masuk ke masalah ini.

5.2.1.4. Item Disediakan: Field `Provides`

Field ini memerkenalkan konsep yang sangat menarik dari sebuah “paket virtual”. Memiliki banyak aturan, namun dua yang terkadang penting. Aturan pertama berupa penggunaan paket virtual menghubungkan layanan umum dengannya (paket “menyediakan” layanan). Kedua menandakan bahwa paket menggantikan yang lainnya, dan dengan tujuan ini dapat juga memenuhi ketergantungan yang dipenuhi lainnya. Memungkinkan untuk membuat pengganti paket tanpa menggunakan nama paket yang sama.

5.2.1.4.1. Menyediakan sebuah “Layanan”

Mari membahas kasus pertama secara lebih mendetail dengan sebuah contoh: seluruh server mail, seperti postfix atau sendmail dikatakan “menyediakan” paket virtual mail-transport-agent. Nah, beberapa paket memerlukan layanan ini agar berfungsi (mis. manajer mailing list, seperti smartlist atau sympa) hanya perlu menyatakan ketergantungannya memerlukan mail-transport-agent daripada menentukan daftar banyak solusi yang memungkinkan namun tak lengkap (mis. postfix | sendmail | exim4 | …). Lebih jauh, sangat tidak berguna untuk memasang dua server mail di mesin yang sama, itulah mengapa setiap paket ini menjelaskan konflik dengan paket virtual mail-transport-agent. Konflik antara suatu paket dan dirinya sendiri diabaikan oleh sistem, namun teknik ini akan menghalangi instalasi dua server mail berdampingan.

DEBIAN POLICY Daftar paket virtual

Agar paket virtual bermanfaat, setiap orang harus setuju dengan penamaannya. Oleh karena itu, hal ini terstandarisasi di Debian Policy. Termasuk di antaranya mail-transport-agent untuk server mail, c-compiler untuk compiler bahasa pemrograman C, www-browser untuk peramban web, httpd untuk server web, ftp-server untuk server FTP, x-terminal-emulator untuk emulator terminal dalam mode grafis (xterm), dan x-window-manager untuk manajer jendela.

The full list can be found on the Web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. Ketergantian dengan Paket Lain

The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.32.1 present in Bullseye). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.

Gambar 5.1. Penggunaan field Provides untuk mengabaikan ketergantungan

Fitur ini sangat berguna, karena tak mungkin untuk mengantisipasi lika-liku pengembangan, dan perlu untuk mengatur penamaan, dan penggantian otomatis lainnya, dari perangkat lunak yang usang.

KEMBALI KE DASAR Perl, sebuah bahasa pemrograman

Perl (Practical Extraction and Report Language) merupakan bahasa pemrograman yang sangat populer. Memiliki banyak modul yang siap digunakan yang mencakup spektrum luas dari aplikasi, dan distribusikan oleh server CPAN (Comprehensive Perl Archive Network), sebuah jaringan paket Perl yang lengkap.

→ https://www.perl.org/

→ https://www.cpan.org/

Karena merupakan bahasa interprete, program yang ditulis dalam Perl tidak memerlukan kompilasi untuk dieksekusi. Oleh karena itu, mereka disebut “Perl scripts”.

5.2.1.4.3. Batasan Masa Lalu

Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.

This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

5.2.1.5. Mengganti Berkas: Field `Replaces`

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.

Penggunaan field ini adil ketika nama paket berganti atau ketika paket di sertakan pada paket lainnya. Hal ini juga terjadi ketika maintainer memutuskan untuk mendistribusikan berkas dengan cara yang berbeda antara berbagai paket biner yang dibuat dari paket sumber yang sama: pengganti berkas tidak lagi dimiliki paket lama, namun hanya yang baru.

Jika seluruh berkas pada paket terinstall telah diganti, paket tersebut dianggap perlu untuk dihapus. Akhirnya, field ini juga mendorong dpkg untuk menghapus paket yang diganti ketika ada konflik.

LEBIH JAUH Field Tag

In the apt example at the beginning, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who dislike aptitude's search criteria, the following website allows navigation of the tag database:

→ https://wiki.debian.org/Debtags

5.2.2. Skrip Konfigurasi

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

LEBIH JAUH basisdata dpkg

Seluruh skrip konfigurasi untuk paket terinstall disimpan di folder /var/lib/dpkg/info/, dalam bentuk berkas yang diawali dengan nama paketnya. Direktori ini juga menyertakan berkas dengan ekstensi .list untuk setiap paket, berisi daftar berkas yang dimiliki paket tersebut.

Berkas /var/lib/dpkg/status berisi beberapa seri blok data (dalam format mail header yang terkenal, RFC 2822) menjelaskan status setiap paket. Informasi dari berkas control paket terinstall juga direplikasi di sana.

Umumnya, skrip preinst dieksekusi sebelum instalasi paket, sedangkan postinst mengikutinya. Begitu pula, prerm dipanggil sebelum penghapusan sebuah paket dan postrm setelahnya. Pembaruan sebuah paket sama dengan penghapusan versi sebelumnya dan instalasi yang baru. Tidak memungkinkan untuk menjelaskan secara mendetail seluruh kemungkinan skenario di sini, namun kita akan membahas dua yang paling umum: instalasi/pembaruan dan penghapusan.

5.2.2.1. Instalasi dan Pembaharuan

During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.

During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.

Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:

For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).
Berkas-berkas paket baru kemudian dibongkar. Jika berkas telah ada, diganti, namun salinan backup dibuat untuk sementara.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
dpkg memerbarui semua data internal (daftar berkas, skrip konfigurasi, dll.) dan membuang backup berkas yang tergantikan. Inilah maksud dari tidak ada kembali: dpkg tidak lagi dapat mengakses elemen yang diperlukan untuk kembali ke kondisi sebelumnya.
dpkg akan memerbarui berkas konfigurasi, menanyakan pengguna untuk memutuskan jika tidak dapat secara otomatis mengatur tugas ini. Prosedur ini dibahas secara mendetail di Bagian 5.2.3, “Checksums, List of Configuration Files, et al.”.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Penghapusan Paket

The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:

dpkg calls the prerm script and passes the remove argument.
dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.
For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.

KOSAKATA Purge, penghapusan maksimal

Ketika sebuah paket Debian dihapus, berkas konfigurasi dipertahankan agar memfasilitasi kemungkinan instalasi ulang. Demikian pula data yang dihasilkan oleh sebuah daemon (seperti konten sebuah direktori server LDAP, atau konten sebuah basisdata untuk server SQL) biasaya dipertahankan.

Untuk menghapus seluruh data yang berhubungan dengan sebuah paket, perlu mem-“purge” paket dengan perintah, dpkg -P paket, apt-get remove --purge paket, atau aptitude purge paket.

Mengingat sifat definitif penghapusan data tersebut, pembersihan tidak boleh dianggap enteng.

Empat skrip yang dijelaskan di atas dilengkapi oleh skrip config, disediakan oleh paket menggunakan debconf untuk mendapatkan informasi dari pengguna untuk konfigurasi. Selama instalasi, skrip ini menentukan secara mendetail pertanyaan yang diminta oleh debconf. Responnya direkaom dalam basisdata debconf untuk preferensi mendatang. Skrip umumnya dieksekusi oleh apt sebelum instalasi paket satu demi satu agar mengelompokkan pertanyaan dan memintanya semua ke pengguna pada awal proses. Skrip instalasi pre- dan post- kemudian dapat menggunakan informasi ini untuk beroperasi berdasarkan keinginan pengguna.

ALAT debconf

debconf telah dibuat untuk menyelesaikan permasalahan yang berulang di Debian. Seluruh paket Debian tidak dapat berfungsi tanpa konfigurasi minimum yang seharusnya diminta dengan memanggil perintah echo dan read dalam postinst skrip shell (dan skrip lain yang serupa). Namun ini juga bermaksud bahwa selama instalasi atau pembaharuan pengguna harus bersama komputernya untuk merespon berbagai pertanyaan yang mungkin muncul kapan saja. Interaksi manual ini hampir seluruhnya telah ditiadakan, terimakasih untuk alat debconf.

debconf memiliki banyak fitur menarik: pengembang perlu menentukan interaksi pengguna; menyediakan lokalisasi seluruh string yang ditampilkan ke pengguna (seluruh terjemahan disimpan di berkas templates menjelaskan interaksi); memiliki antarmuka berbeda untuk menampilkan pertanyaan ke pengguna (mode teks, mode grafis, non-interaktif); dan mengizinkan pembuatan basisdata sentral dari respon untuk berbagi konfigurasi yang sama dengan beberapa komputer... namun hal yang paling penting ialah sekarang memungkinkan seluruh pertanyaan dalam satu baris kepada pengguna, sebelum memulai instalasi atau proses pembaharuan yang panjang. Pengguna dapat pergi dengan urusan mereka ketika sistem menangani instalasinya sendiri, tanpa perlu berada di depan layar menanti pertanyaan.

5.2.3. Checksums, List of Configuration Files, et al.

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files.

The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Bagian 14.3.4.1, “Mengaudit Paket-paket dengan dpkg --verify”) and debsums (from the package of the same name; see Bagian 14.3.4.2, “Mengaudit Paket: debsums dan keterbatasannya”) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

Efeknya, dalam situasi ini, dpkg bertindak secerdas mungkin: jika berkas konfigurasi standar tidak berubah antara kedua versi, tidak dilakukan apapu. Akan tetapi, jika berkas telah berubah, akan mencoba untuk memebarui berkas ini. Duah kasus yang mungkin: antara administrator tidak menyentuh berkas konfigurasi ini, dalam hal ini dpkg menginstall versi baru secara otomatis; atau berkas telah dimodifikasi, dalam hal ini dpkg meminta administrator versi mana yang ingin digunakan (versi lama yang dimodifikasi, atau yang baru yang disediakan oleh paket). Untuk membantu memutuskan, dpkg menawarkan untuk menampilkan sebuah “diff” yang menunjukkan perbedaan antara dua versi. Jika pengguna memilin untuk memertahankan versi lama, yang baru akan disimpan di lokasi yang sama dalam berkas dengan akhiran .dpkg-dist. Jika pengguna memilih versi baru, yang lama akan dipertahankan dalam sebuah berkas dengan akhiran .dpkg-old. Yang lainnya aksi yang tesedia berisi mengganggu sesaat dpkg untuk menyunting berkas dan berusaha mengatur kembali modifikasi yang sesuai (sebelumnya teridentifikasi oleh diff).

LEBIH JAUH Paksa dpkg untuk menanyakan permintaan berkas konfigurasi

Pilihan --force-confask memerlukan dpkg untuk menampilkan pertanyaan tentang berkas konfigurasi, bahkan ketika mereka normalnya tidak diperlukan. Yaitu, ketika menginstall ulang sebuah paket dengan pilihan ini, dpkg akan menanyakannya lagi untuk seluruh berkas konfigurasi yang dimodifikasi atau dihapus oleh administrator. Ini sangat mudah, khususnya untuk menginstall ulang berkas konfigurasi asli jika telah dihapus dan salinannya tidak tersedia: penginstal-ulangan tidak bekerja, karena dpkg memutuskan penghapusan sebagai bentuk legitimasi modifikasi, dan, hal tersebut, tidak menginstall berkas konfigurasi yang diinginkan.

See the sidebar LEBIH JAUH Menghindari pertanyaan berkas konfigurasi for how to use these options with APT.

LEBIH JAUH Menghindari pertanyaan berkas konfigurasi

dpkg menangani pembaharuan berkas konfigurasi, namun, ketika melakukannya, seringkali menginterupsi pekerjaannya untuk meinta masukan dari administrator. Hal ini membuat kurang menarik untuk mereka yang ingin menjalankan pembaharuan dengan cara non-interaktif. Oleh karena itu, program ini menawarkan pilihan yang memungkinkan sistem merespon secara otomatis berdasarkan logika yang sama: --force-confold memertahankan berkas versi lama; --force-confnew akan menggunakan berkas versi baru (pilihan ini masing-masing, bahkan jika berkas tidak diubah oleh administrator, yang jarang sekali efeknya diinginkan). Menambahkan pilihan --force-confdef menunjukkan dpkg untuk memutuskan sendiri ketika dimungkinkan (dengan kata lain, ketika berkas konfigurasi asli belum disentuh), dan hanya menggunakan --force-confnew atau --force-confold untuk kasus lain.

Pilihan ini berlaku untuk dpkg dan dijelaskan secara rinci dalam dpkg(1) atau dpkg --force-help, namun sering kali administrator langsung bekerja dengan program aptitude atau apt. Jadi, penting untuk mengetahui sintaks yang digunakan untuk mengindikasikan pilihan yang dilewatkan ke perintah dpkg (antarmuka baris perintahnya sangat mirip).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

These options can also be stored directly in apt's configuration. To do so, simply write the following lines in the /etc/apt/apt.conf.d/local file:

Dpkg::Options {
  "--force-confdef";
  "--force-confold";
}

Termasuk pilihan ini di berkas konfigurasi berarti bahwa ini juga digunakan di antar muka grafis seperti aptitude.

The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).

Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in /usr/share/doc/dpkg/triggers.txt.gz.

The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.