45

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?

Sam Brightman
  • 745
  • 1
  • 7
  • 12
  • 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 '09 at 09: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". :( – Sam Brightman Dec 01 '09 at 14:22

4 Answers4

27

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,052
  • 1
  • 15
  • 9
  • I must have missed these options, thanks. -I doesn't seem to show much though - looks like first line (interrobang) only. – Sam Brightman Nov 27 '09 at 11:15
  • 3
    Note: You need to have the package file available locally. Download it first via 'aptitude download '. – Martijn Heemels May 10 '11 at 12:36
  • 3
    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 '14 at 02:14
10

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
  • 9,851
  • 4
  • 33
  • 44
  • 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. – Sam Brightman Nov 27 '09 at 11:14
6

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
  • 296
  • 3
  • 3
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
  • 95,029
  • 29
  • 173
  • 228
  • 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. – Sam Brightman Nov 27 '09 at 11:08