60

I would like to be able to view the scripts/triggers associated with a package due for upgrade so that I can tell, for example, whether it will result in the web server being restarted. I can't find an aptitude option to show me that (or apt/dpkg); the best I can get is the contents (files). Is there some combination of simulate/verbose/contents switches that I have missed that will show this?

Additionally, if a package results in something happening - like a service restart - that I don't want to happen right now, is there a way to install the package without running some or all of the scripts?

5 Answers5

38

You can print the control file and some other information with dpkg -I package.deb, or use dpkg -e package.deb to extract only the control information files.

Also, you can do a dry run to see what dpkg would do with --dry-run:

dpkg --dry-run -i package.deb
Mikael S
  • 2,480
12

No, I don't know of any way to do this using aptitude.

You can look at the scripts directly; the scripts that run during upgrade are contained in the package. Unpack the deb using ar:

ar -x package.deb

Then look into control.tar.gz, it contains the scripts.

sleske
  • 10,234
12

There is also the --debug option for dpkg, as in sudo dpkg --debug=72200 -i package.deb

There are several available options for verbose output and they can be combined.

You can see all available options by running: dpkg --debug=help.

pi@kaldi:~ $ dpkg --debug=help
dpkg debugging option, --debug=<octal> or -D<octal>:

 Number  Ref. in source   Description
      1  general          Generally helpful progress information
      2  scripts          Invocation and status of maintainer scripts
     10  eachfile         Output for each file processed
    100  eachfiledetail   Lots of output for each file processed
     20  conff            Output for each configuration file
    200  conffdetail      Lots of output for each configuration file
     40  depcon           Dependencies and conflicts
    400  depcondetail     Lots of dependencies/conflicts output
  10000  triggers         Trigger activation and processing
  20000  triggersdetail   Lots of output regarding triggers
  40000  triggersstupid   Silly amounts of output regarding triggers
   1000  veryverbose      Lots of drivel about eg the dpkg/info directory
   2000  stupidlyverbose  Insane amounts of drivel

Debugging options can be mixed using bitwise-or.
Note that the meanings and values are subject to change.
estibordo
  • 386
5

the file

ls /var/lib/dpkg/info/*.*{inst,rm}
  • preinst
  • prerm
  • postinst
  • postrm

the cmd

dpkg -e XXX.deb //extract control files, got a DEBIAN dir

as @dwurf mentioned

dpkg -x XXX.deb OUT //extract data files, got a OUT dir
dpkg -i --debug=77777 XXX.deb //see install detail (and do install)

as @estibordo mentioned

help detail

from man dpkg

-e, --control archive [directory]
    Extract control-information from a package.

-x, --extract archive directory Extract the files contained by package.

-Doctal, --debug=octal Switch debugging on. octal is formed by bitwise-ORing desired values together

Number Description 1 Generally helpful progress information 2 Invocation and status of maintainer scripts 10 Output for each file processed 100 Lots of output for each file processed 20 Output for each configuration file 200 Lots of output for each configuration file 40 Dependencies and conflicts 400 Lots of dependencies/conflicts output 10000 Trigger activation and processing 20000 Lots of output regarding triggers 40000 Silly amounts of output regarding triggers 1000 Lots of drivel about e.g. the dpkg/info dir 2000 Insane amounts of drivel

yurenchen
  • 233
1

No, you can't run part of a maintainer script, there's no hooks to make that happen.

You can only view what the script would do by examining it by hand -- again, no "dry run" can tell you exactly what it will and won't do, only "I will run the postinst with these args".

These are the reasons we have staging and test environments.

womble
  • 98,245