我将如何在Fakeroot Deb软件包构建器中使用postinst脚本

Question

Good afternoon,

I was able to build my project into a deb package using:

fakeroot dpkg-deb --build mypackage

Next, I can install the package using

dpkg -i mypackage.deb

Everything is installed and copied correctly when I do this, however I would like to run a few bash commands after the package is installed.

I understand this needs to be done using the postinst file in the mypackage/DEBIAN directory

I have seen a few examples of this script online, but no clear explanation of how to write one and how to include it in the build.

1. How do I make sure fakeroot dpkg-deb includes this script, is placing it into DEBIAN directory enough?

2. There is a case structure in the postinst script, what is this for, and where do I place the bash commands to execute in that script

3. If I install the package with dpkg - i mypackage.deb is this enough to run that script?

An example script I would like to make is shown below.

4. What do " configure, abort-upgrade, abort-remove, and abort-deconfigure " stand for.

5. What does the " update-alternatives " line do.

Thank you for your help,

postinst file below.

#!/bin/sh

set -e

case "$1" in
    configure)
        # EXECUTE MY BASH COMMAND
        echo /usr/local/lib > /etc/ld.so.conf && ldconfig
    ;;

    abort-upgrade|abort-remove|abort-deconfigure)
        exit 0
    ;;

    *)
        echo "postinst called with unknown argument \`$1'" >&2
        exit 1
    ;;
esac

update-alternatives --install /usr/bin/fakeroot fakeroot /usr/bin/fakeroot-ng 5 \
        --slave /usr/share/man/man1/fakeroot.1.gz \
            fakeroot.1.gz /usr/share/man/man1/fakeroot-ng.1.gz

exit 0

Answer 1

First, here is possibly the most relevant documentation: Debian Policy Manual: Package Maintainer Scripts and Installation Procedure .

Second, the very most important thing to remember when writing or dealing with maintainer scripts is that they must be idempotent. Assume the script will be run many times in succession, and make sure things still won't break if so.

To answer your questions directly,

1. Putting it in the DEBIAN directory is correct, when building with dpkg-deb . If you were instead using Debhelper for a safer or more convenient build setup, you might put the postinst in debian/$packagename.postinst .

2. The postinst script can be called in a number of different situations. The "case" statement you can find in many (most?) postinsts is meant to check which situation it is. Generally speaking, it makes sense to take most postinst actions in all of the possible situations, and that's why they are grouped together in one script. But sometimes it is better to differentiate. I'll explain the different scenarios under #4.

3. Yes. A successful installation of a deb package (whether by dpkg -i , apt-get install , or whatever) must involve a successful run of its preinst and postinst scripts, if present. It is possible to "unpack" a deb without running any maintainer scripts, but that is not considered "installing".

4. These "action" names correspond to the different situations in which a postinst can be run.

   • configure : A package is being installed or upgraded. If the package wasn't installed before, $2 will be empty. Otherwise $2 will contain the old version number of the package; the version from which you are upgrading.

   • abort-upgrade : An upgrade operation was aborted. As an example, I have version V1 of mypkg installed, and I try to upgrade it to V2. But the preinst or postinst of V1 fail to run successfully, or there is a file conflict. dpkg stops trying to install V2, and re-runs the postinst from V1 (with the " abort-upgrade " action) in case any state needs to be restored.

   • abort-remove : A remove operation was aborted. For example, if I ran "dpkg -P mypkg", but mypkg's prerm script failed to run, or something else happened that made dpkg think it could not safly uninstall mypkg. So it runs mypkg's postinst again (with the " abort-remove " action) in case any state needs to be restored.

   • abort-deconfigure : As you might guess, a deconfigure operation was aborted. "deconfiguring" is sort of a half-removal action used when a package being installed conflicts with others already installed. To make the explanation short, if the abort-deconfigure action is being run, the postinst is expected to restore any state that might have been undone by the prerm script with the deconfigure action.

   For lots of additional nitty-gritty details, see the great charts and explanations at https://people.debian.org/~srivasta/MaintainerScripts.html .

5. The "update-alternatives" command updates entries in the Debian "alternatives" system. See the man page. In this specific case, the command is telling Debian that " /usr/bin/fakeroot-ng " is an alternative for the fakeroot command. Depending on the priority of this alternative and the priority of other registered alternatives, and the preference of the user, fakeroot-ng might now be invoked when someone runs " fakeroot ".

Answer 2

Just one think about this line :

echo /usr/local/lib > /etc/ld.so.conf && ldconfig

According the Debian Policy, you shouldn't modify ld.so.conf

A simple alternative is to do something like that :

In your postinst script :

/usr/local/lib > /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig

and in your postrm script :

rm /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig