Thanks for your prompt response. Here is what I did:
root@server:~# man 5 dpkg-dev
No manual entry for dpkg-dev in section 5
root@server:~# man 7 dpkg-dev
No manual entry for dpkg-dev in section 7
root@server:~# man dpkg-dev
No manual entry for dpkg-dev
There are no dpkg-dev packages to install or its under a different name.
root@thor:~# uname -a
Linux thor 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64
root@thor:~# cat /etc/issue
Debian GNU/Linux 8 \n \l
I am running the latest Debian.
Do you know what might be going on above?
I will look into triggers file.
On 3/6/18 3:52 AM, Guillem Jover wrote:
On Mon, 2018-03-05 at 17:48:13 -0800, Count of San Francisco wrote:
I went to your main webpage (https://wiki.debian.org/Teams/Dpkg) to try to
understand the design and architecture of dpkg, itself. I am thinking of
using this for a personal embedded project and need to try to assess its
feasibility in my project. However, I cannot find any document on the actual
design or architecture of dpkg, itself. Do you have any documents that
describes how the actual design works?
I guess that depends on what specific design you are thinking about.
For example, there are several man pages describing file formats in
the dpkg-dev package (in section 5), the version format and algorithm
(in section 7).
The behavior of dpkg with packages and towards maintainer scripts is
described in the Debian Policy manual. But some things are not yet
documented there, such as multiarch or triggers (the former is
currently documented in the man pages and the spec, latter is
documented in the man pages and in doc/triggers.txt).
The source formats and their usage are documented also in the Debian
Policy manual and the dpkg-source man page.
Ideally dpkg would be self-contained when it comes to documentation
describing its behavior and interfaces, but for historical reasons
most of those docs got moved wholesale into the Debian Policy. I've
been trying to document back the dpkg specific things, but that takes
Or, do I need to read the dpkg code and reverse engineer it? I know
how it works from a user perspective when installing a package on a
Debian system but that is not what I am after.
If the above is not enough, it would help if you described what
exactly you want to know.
Lastly, I see that perl is used. Is that only used for compilation
of dpkg or is it needed in the actual execution of dpkg or both?
dpkg (the project) has two (well three) main parts, one deals with
binary packages and run-time installation, database, etc, which is
written in C and shell script (the contents of the dpkg.deb package),
the other deals with source packaging and building and is written in
perl (the contents of dpkg-dev.deb and libdpkg-perl.deb), and the
last one is a much maligned TUI frontend for dpkg (in the dselect.deb