51

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?

2
  • Why was this voted down? It seems like a reasonable question to me (even though doing something like this should not normally be necessary).
    – sleske
    Nov 30, 2009 at 9:29
  • 2
    Beats me. No particularly abrasive comments or answers, just random downvote. As if "normally shouldn't be done" is the same as "never should be done under any circumstances and not even educational". :( Dec 1, 2009 at 14:22

5 Answers 5

31

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
3
  • I must have missed these options, thanks. -I doesn't seem to show much though - looks like first line (interrobang) only. Nov 27, 2009 at 11:15
  • 3
    Note: You need to have the package file available locally. Download it first via 'aptitude download <packagename>'. May 10, 2011 at 12:36
  • 5
    The -e option will create a DEBIAN directory with the control file and the various script files that will be run. postinst is usually very interesting as it will be executed after the package is successfully installed.
    – dwurf
    Mar 31, 2014 at 2:14
11

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.

1
  • Would be better if aptitude -s with some verbosity options actually showed the scripts it would run for the whole upgrade. That's essentially what I was asking for, but I think Mikael's answer is slightly simpler. Nov 27, 2009 at 11:14
8

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.
3
  • That will still do the installation though, won't it? Aug 16, 2019 at 1:16
  • Yes, are 100% right. This must be done in another (development) instance.
    – estibordo
    Aug 16, 2019 at 9:17
  • You can get all debug by dpkg -i --debug=77777 <package_name> Apr 10, 2022 at 15:53
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.

1
  • I meant a subset of the scripts, not part of an individual script. Sorry if that wasn't clear. I don't want magic, knowing the script and the arguments allows me to hand inspect, or modify the parts that are inconvenient. Nov 27, 2009 at 11:08
1

🔵 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.