TuT Debian Packaging - Part 2

[castix 18.4k iPhone X 12.1.1]

What is a Debian control file
 

 

Specifics regarding the contents of a Debian control file are provided in the Debian Policy Manual

Briefly, a sample control file is shown below for the Debian package Test:

Package: Test
Priority: optional
Section: devel
Installed-Size: 45
Maintainer: castix <[email protected]>
Architecture: iphoneos
Version: 1.3-16
Depends: libc6 (>= 2.1)
Description: The classic greeting, and a good example The GNU hello program produces a familiar, friendly greeting.  It
             allows nonprogrammers to use a classic computer science tool which
             would otherwise be unavailable to them.

Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Project's `hello world' program (which is itself an example for the GNU Project).

The Package field gives the package name.  This is the name by which the package can be manipulated by the package tools, and usually similar to but not necessarily the same as the first component string in the Debian archive file name. The Version field gives both the upstream developer's version number and (in the last component) the revision level of the Debian package of this program. The Architecture field specifies the chip for which this particular binary was compiled. The Depends field gives a list of packages that have to be installed in order to install this package successfully. The Installed-Size indicates how much disk space the installed package will consume.  This is intended to be used by installation front-ends in order to show whether there is enough disk space available to install the program. The Section line gives the "section" where this Debian package is stored at the Debian FTP sites. The Priority indicates how important is this package for installation, so that semi-intelligent software like dselect or aptitude can sort the package into a category of e.g.  packages optionally installed. The Maintainer field gives the e-mail address of the person who is currently responsible for maintaining this package. The Description field gives a brief summary of the package's features.

 

 

 

 

What is a Debian conffile


Conffiles is a list of configuration files (usually placed in `/etc') that the package management system will not overwrite when the package is upgraded.  This ensures that local values for the contents of these files will be preserved, and is a critical feature enabling the in-place upgrade of packages on a running system.

To determine exactly which files are preserved during an upgrade, run:

  dpkg --status package

And look under "Conffiles:".
 

 

 

 

 

 

What is a Debian preinst, postinst, prerm, and postrm script


These files are executable scripts which are automatically run before or after a package is installed.  Along with a file named `control', all of these files are part of the "control" section of a Debian archive file.

The individual files are:

preinst This script executes before that package will be unpacked from its Debian archive (".deb") file.  Many 'preinst' scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the 'postinst' script).

 

postinst This script typically completes any required configuration of the package `foo' once `foo' has been unpacked from its Debian archive (".deb") file.  Often, 'postinst' scripts ask the user for input, and/or warn the user that if he accepts default values, he should remember to go back and re-configure that package as the situation warrants.  Many 'postinst' scripts then execute any commands necessary to start or restart a service once a new package has been installed or upgraded.

prerm This script typically stops any daemons which are associated with a package.  It is executed before the removal of files associated with the package.

postrm This script typically modifies links or other files associated with `foo', and/or removes files created by the package. 

 

Currently all of the control files can be found in directory `/var/lib/dpkg/info'.  The files relevant to package `foo' begin with the name "foo" and have file extensions of "preinst", "postinst", etc., as appropriate.  The file `foo.list' in that directory lists all of the files that were installed with the package `foo'.  (Note that the location of these files is a dpkg internal; you should not rely on it.)

 

 

 

 

 

 

What is an Essential, Required, Important, Standard, Optional, or Extra package
 

 

Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system.  The priorities are:

▪ Required: packages that are necessary for the proper functioning of the system. This includes all tools that are necessary to repair system defects.  You must not remove these packages or your system may become totally broken and you may probably not even be able to use dpkg to put things back.  Systems with only the Required packages are probably unusable, but they do have enough functionality to allow the sysadmin to boot and install more software.

▪ Important packages should be found on any Unix-like system. Other packages which the system will not run well or be usable without will be here.  This does NOT include Emacs or X or TeX or any other large applications.  These packages only constitute the bare infrastructure.

▪ Standard packages are standard on any Linux system, including a reasonably small but not too limited character-mode system. Tools are included to be able to browse the web (using w3m), send e-mail (with mutt) and download files from FTP servers. This is what will install by default if users do not select anything else.  It does not include many large applications, but it does include the Python interpreter and some server software like OpenSSH (for remote administration), Exim (for mail delivery, although it can be configured for local delivery only), an identd server (pidentd) and the RPC portmapper (`portmap'). It also includes some common generic documentation that most users will find helpful.

 

▪ Optional packages include all those that you might reasonably want to install if you did not know what it was, or do not have specialized requirements. This includes X, a full TeX distribution, and lots of applications.

▪ Extra: packages that either conflict with others with higher priorities, are only likely to be useful if you already know what they are, or have specialized requirements that make them unsuitable for "Optional". If you do a default Debian installation all the packages of priority Standard or higher will be installed in your system.  If you select pre-defined tasks you will get lower priority packages too. Additionally, some packages are marked as Essential since they are absolutely necessary for the proper functioning of the system.  The package management tools will refuse to remove these.

 

 

 

 

 

 

 

What is meant by saying that a package Depends, Recommends,Suggests, Conflicts, Replaces, Breaks or Provides another package


The Debian package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system:

▪ Package A depends on Package B if B absolutely must be installed in order to run A.  In some cases, A depends not only on B, but on a version of B.  In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version.

▪ Package A recommends Package B, if the package maintainer judges that most users would not want A without also having the functionality provided by B.

▪ Package A suggests Package B if B contains files that are related to (and usually enhance) the functionality of A.

▪ Package A conflicts with Package B when A will not operate if B is installed on the system.  Most often, conflicts are cases where A contains files which are an improvement over those in B. "Conflicts" are often combined with "replaces".

▪ Package A replaces Package B when files installed by B are removed and (in some cases) over-written by files in A.

▪ Package A breaks Package B when both cannot packages cannot be simultaneously configured in a system.  The package management system will refuse to install one if the other one is already installed and configured in the system.

▪ Package A provides Package B when all of the files and functionality of B are incorporated into A.  This mechanism provides a way for users with constrained disk space to get only that part of package A which they really need.
 

 

 

 

 

 

What is meant by Pre-Depends


"Pre-Depends" is a special dependency.  In the case of most packages, `dpkg' will unpack its archive file (i.e., its `.deb' file) independently of whether or not the files on which it depends exist on the system.  Simplistically, unpacking means that `dpkg' will extract the files from the archive file that were meant to be installed on your file system, and put them in place.  If those packages depend on the existence of some other packages on your system, `dpkg' will refuse to complete the installation (by executing its "configure" action) until the other packages are installed. However, for some packages, `dpkg' will refuse even to unpack them until certain dependencies are resolved.  Such packages are said to "Pre-depend" on the presence of some other packages.  The Debian project provided this mechanism to support the safe upgrading of systems from `a.out' format to `ELF' format, where the order in which packages were unpacked was critical.  There are other large upgrade situations where this method is useful, e.g.  the packages with the required priority and their LibC dependency. As before, more detailed information about this can be found in the Policy manual.
 

 

 

 

 

 

What is meant by unknown, install, remove, purge and hold in the package status


These "want" flags tell what the user wanted to do with a package (as indicated either by the user's actions in the "Select" section of `dselect', or by the user's direct invocations of `dpkg').

Their meanings are:

▪ unknown - the user has never indicated whether he wants the package

▪ install - the user wants the package installed or upgraded

▪ remove - the user wants the package removed, but does not want to remove any existing configuration files.

▪ purge - the user wants the package to be removed completely, including its configuration files.

▪ hold - the user wants this package not to be processed, i.e., he wants to keep the current version with the current status whatever that is.
 

 

 

 

 

 

 

How do I install a source package


Debian source packages can't actually be "installed", they are just unpacked in whatever directory you want to build the binary packages they produce. Source packages are distributed on most of the same mirrors where you can obtain the binary packages.  If you set up your APT's sources.list(5) to include the appropriate "deb-src" lines, you'll be able to easily download any source packages by running

apt-get source foo

To help you in actually building the source package, Debian source package provide the so-called build-dependencies mechanism.  This means that the source package maintainer keeps a list of other packages that are required to build their package.  To see how this is useful, run

apt-get build-dep foo

before building the source.

 

 

 

 

 

 

How do I build binary packages from a source package


The preferred way to do this is by using various wrapper tools. I'll show how it's done using the `devscripts' tools.  Install this package if you haven't done so already.

Now, first get the source package:

apt-get source foo

and change to the source tree:

cd foo-*

Then install needed build-dependencies (if any):

sudo apt-get build-dep foo

Then create a dedicated version of your own build (so that you won't get confused later when Debian itself releases a new version)

dch -l local 'Blah blah blah'

And finally build your package

debuild -us -uc

If everything worked out fine, you should now be able to install your package by running

sudo dpkg -i ../*.deb

If you prefer to do things manually, and don't want to use `devscripts', follow this procedure:

You will need all of foo*.dsc, foo*.tar.gz and foo*.diff.gz to compile the source (note: there is no .diff.gz for some packages that are native to Debian). Once you have them, if you have the `dpkg-dev' package installed, the following command:

dpkg-source -x foo_version-revision.dsc

will extract the package into a directory called `foo-version'. If you want just to compile the package, you may cd into `foo-version' directory and issue the command

dpkg-buildpackage -rfakeroot -b

to build the package (note that this also requires the `fakeroot' package), and then

dpkg -i ../foo_version-revision_arch.deb

to install the newly-built package(s).

 

 

 

As always thanks for reading, 

 

castix

 

[Rook 536k iPad Pro (2nd gen) 17.4 Donor]

Isn't dpkg -b to build?

[Amuyea 87.4k iPhone 7 Plus 14.3]

Write a book

[KingRalph 808 9.3.5]

@@castix One problem, sudo does not come with Apple devices. You have to go into terminal and type:

sualpinedpkg -i ../*.deb

Instead of

sudo dpkg -i ../*.deb

[castix 18.4k iPhone X 12.1.1]

@@castix One problem, sudo does not come with Apple devices.

You can get sudo from Cydia

[KingRalph 808 9.3.5]

You can get sudo from Cydia

Ok